cms

Не могу промолчать - тоже не так давно начал проект Xilinx после 8 лет альтеры. Захотелось новизны, хе-хе. Приговор тулам от Xilinx: пользоваться им без синплифая - это мазохизм. В отличие от Альтеры, у которой в квартусе стоит замечательный HDL-синтезатор с SystemVerilog и поддержкой VHDL-2008, ксалиновский XST еле справляется с verilog-2001. Об SV там речи и не идет. Причем качество синтеза - я рыдал. XST полтора (1.5!) часа терзает проектик, который квартус и синплифай проглатывают за 15-20 минут (ессно на той же машине). И выдает после этого на треть худший результат по ресурсам и времянке. Отдельно хочу сказать про xreport - я до сих пор не понял как у этого гаденыша поменять шрифт под линуксами. Нет у него такой опции и все! и qtconfig не действует, и xilinx молчит... Приходится всю эту xml-шину смотреть в браузере. И CoreGen после альтеровских мегафункций - грустное зрелище. Сами ксалиновские IPшники дубовые и плохо документированные. Например DDR контроллер имеет только глобальный ресет, и никакого тебе soft-ресета как у альтеры или просто flush очередей. С тоской вспоминаю содержательные и аккуратные альтеровские доки. Сам ISE под линуксом - так себе, кое-как привык, но пользы от него особой не чувствую переходить с ксалинском надо на чистую коммандную строку.

искупил.

По нынешним временам герой не тот кто что-то предложил, а тот кто это пропихнул в массы. Ребята взяли и довели обстрактную идею до промышленного уровня. Хваляться, что забили на ней 80 патентов. А то что издали похожих фич много кругом - это ничуть их работу не умаляет. Я кстати, догадываюсь как они заделали свою реконфигурацию - на каждый коммутационный гейт повесили не однобитный RAM, а 8-битный регистр с управляющей обвеской. И крутят его по циклу. Правда не совсем понятно как они на 1.6ГГц клоке успевают сменить конфигурацию и прогнать на ней такт вычислений. Откуда инфа про Altera, AMD и LSI? Почему вы уверены что там нет ребят из ex-USSR? Я вот во многих местах их видал. Особенно в окресностях Сан-Франциско.

$write("%x",4'b1101); Вот HDL-решение эквивалентное решению на ЯП.

Гипотеза не верная. 65nm LP Single-Port SRAM Block 2Kx16 mux4 113.00x313.00 = 35292um^2 65nm LP Dual-Port SRAM Block 2Kx16 mux4 185.00x454.00 = 83990um^2 83990 / 35292 = 2.38

Для 0.35 это так. Для более мелких техпроцессов 65nm LP Single-Port SRAM cell 1.05 X 0.5 = 0.525um^2 65nm LP Dual-Port 8T SRAM cell = 0.97um^2 65nm LP Single-Port SRAM Block 128x32 mux4 176.00x67.00 = 11792um^2 65nm LP Dual-Port SRAM Block 128x32 mux4 307.00x68.00 = 20876um^2 20876 / 11792 = 1,77 Для 40 нм коэффициент подтягивается к двойке еще ближе.

Анонсировали еще одну FPGA будущего. И что интересно, руководит этой затеей опять-таки беженец из Xilinx. Я пару лет назад уже постил на electronix о новых ПЛИС спроектированными Xilinxовскими отщепенцами - правда тогда боролись за LowPower, а сейчас за High-Performance. Что-то разбегается народ из Xilinx во все стороны.

SystemVerilog is a parallel programming language. [iEEE Std 1800]. Это фраза из стандарта самого SV. противопоставлять программистов HDL-дизайнерам бессмысленно. Есть программисты, которые программируют на RTL-уровне. В скором времени этот уровень уйдет из масс в узкие ниши, как ушел уровень схематика и ассемблера. А на сисетмном уровне совсем не факт, что железо описывать на SV будет удобнее чем не матлабе или C++. З.Ы. SV имеет туманное будущее еще и потому что не имеет open-source и универститетской поддержки - это узкоспециализированный индустриальный язык, развивающийся 14 конторами для внутреннего междусобойчика. Фанаты SV не сидят по всему миру и не прикладывают его ко всем возможным теориям, как это происходит с тем же С++. А SV реально обламывается тремя существующими компиляторами, которые до сих пор не могут масив интерфейсов обработать, а параметризацию классов можно нормально только макросами делать - весь VMM это сплошной макрос который потом хрен отладишь.

2 dxp: ну вы просто накрыли всех скептиков ракетным залпом. Пройдусь топориком: программисты не более наглые, они более активные. Легко и непринужденно вторгаются в различные области, в том числе и дзайн железа. Во многих областях достигают успеха, бо теория у них, dxp абсолютно прав, на три поколения опережает текущие мысли в других областях и прикладывают они её творчески и с задором. Наблюдая за развитием SV не оставляет мысль, что Куммингс, Сюзерленд и компания просто осваивают то что занимало умы передовых программеров лет 30 назад - объектное программирование, стандартизация методологии через библиотеку классов VMM по неуклюжести очень напоминает майкрософтовкую MFC двадцатилетней давности. Так что толковым программистам точно что есть сказать по поводу RTL. И они скажут, я в этом не сомневаюсь. С другой стороны сами программисты не стремятся писать все и вся на C - веб пишут на PHP/Java, c базами данных работают на SQL, окошки под винду - на C#, GPU - на OpenCL. По поводу компиляции HDL в програму для CPU - так synopsys VCS тем и занимается, генерит испольняемый бинарник. Компилированный из С алгоритм работает на процессоре быстрее.

Ну не торопитесь пока. Лично мне интересно послушать SM, des00, Sergey'F - то что переодически вклиниваются флудовые посты ничуть не умалаяет ценности соержательных постов. А тема далеко не исчерпана - оно конечно очень хочется сунутьт голову с песок и твердить себе RTL-рулез, С - сакс, но жизнь-то не стоит на месте, подойдет сзади, да так что и голову вытащить не успеешь. Архитектор делает систему, в том числе и выставляет требования к модулям. При этом он отлично понимает как работает железо на всех уровнях. Прежде чем писать статью нормальные люди проверяют свои выкладки на софтварной модели - С или МАТЛАБ. Современный псевдокод - это выдержки из C. Хотя если вы имеете в виду книги 70-80х годов то да, там может быть что угодно. И первая практическая реализация алгоритма с большой вероятностью делается на DSP. Что вы понимаете под функциональными языками?

Три месяца московского инженера стоят больше 4k$. Архитекторы чипов очень хорошо знают аппаратуру, гораздо лучше RTL дизайнеров. На С (или матлабе) пишут ученые. А потом архитекторы, минуя стадию RTL-перекодирования, напрямую используют C-модели и для синтеза, и для верификации. Направление функциональных HLS языков не умерло.

Узость зависит от ракурса наблюдателя. Если заниматься изготовлением дискретной логики (типа 8-битных контроллеров) или бюджетными FPGA-проектами, то да, там необходимо и технически возможно вылизывание топологии и ручное размещение каждого из 2000 гейтов. Но когда вы делает чип для очередного DVD-проигрывателя на пару миллионов гейтов, то тут лучше накидать проверенных корок, добавить новизны какой-нибудь собственным видеофильтром разработанным в матлабе, все это отверифицировать и через полгода уже отгружать кастомерам готовый SoC. P.S. Проценты себестоимости ИМХО эффективнее отжимаются бухгалтерий и менеджментом, нежели утаптыванием кремния.

К сожалению, немного не так. Рынок у поставщиков кубиков очень узкий. Если систем-интегратору нужен нестандартный кубик, он обращается к своему IP-вендору и просит подточить то что есть, а не начинает рыскать по помойкам. NXP вообще отказалось мультивендорных закупок IP, заключив экслюзивный договор на IP-обеспечение с VirageLogic, потому как так проще, эффективнее и дешевле. Тоже самое делают и остальные системщики - им нужно гарантированное качество, а не богатый выбор. Про массовый рынок с маленькими себестоимостями - тоже миф. Себестоимость 300-миллиметровой вафли по 65нм процессу ~2000$, и поджатие площади на 10% ничего не даст по сравнению с потерей полугода или дополнительной итерацией шаблона. Поэтому системщики ставят везде едножды опробованные IP и даже не смотрят на новые предложения, если они минимум в два раза не перебивают текущий вариант по параметрам. Такова реальность. Любой SoC. любой менеджер проекта возмете Спартан-6 за теже деньги и сведет проектные риски к нулю. Невидимая рука рынка обычно берет за яйца тех кто изобретает велосипед.

Рынок профессии сжимается. Уходит рынок систем, остается только разработка компонентов. А в компонентах быстро насупает насыщение. Уже сейчас видно, что огромное количество народа пишет LDPC кодеки - потому как ничего другого писать не надо - там поптимальнее уже все сделано. С видео таже история - чуть ли ни каждый день появляются новые AVC кодеки. 2 des00: А что такое язык ДРАКОН?

des00 говорит мудрые вещи. Model-based system-Level design - это очень интересный вариант. Если посмотреть внимательнее, то окажется, что число используемых алгоритмов в ЦОС вполне себе счетное множество и спустя 10 лет устаканивается в набор эффективных параметризуемых блоков, из которых можно набирать 90% ЦОС систем. Ну а небольшую часть, содержащуюю новизну, можно и на верилоге подписать, если не верите в C или M code-based synthesis. Кстати, SoPC builder отличный пример model-based synthesis. Главное его ограничение - отсутствие высокоуровневого моделирования.

Так, что за разговорчики в строю? Всем горланяшим "этого не может быть, потому что быть не может" командую вольно - с моего запроса на CatapultC evaluation уже прошло 96 часов, хотя на сайте обещали связаться в течении 48. Пора complaint вкатить. А пока снаряды не подвезли, подкидываю свежих баек - Synopsys в своем HLS сделал ставку на M-файлы матлаба в Synphony. Вечной памяти SystemGenerator от Xilinx... А Матлаб, я кстати, тоже люблю.

На слайде 60GHz указано - 1.5 года и limited resources. Сколько инженеров Ментор бросил на Катапульту я не знаю, но если много - то это только говорит в пользу оной. Ибо капиталисты платить за беспереспективный проект толпе народа не будут. Значит уверены в результате. То что хороший тул сделать не просто и то что команду в Питере разогнали ничего не говорит о том что такой тул сделать не возможно. Эти деньги и время затратил Ментор - а пользователь экономит. Это не реклама. Это доклад пользователя на IP-Embedded Systems Conference'09. Это вы горячитесь, H.264 и 60GHz до них из С никто не синтезил. 18 месяцев для электронной индустрии - это большой срок, как раз хватит чтобы все стало гладко, а моделсим не сворачивают потому как за него несут денюжку - кто ж направления сворачивает пока оно еще прибыльное? До широкого круга специалистов дойдет, не сомневаюсь. Но до кого дойдет первым, тот и будет в выигрыше. Насчет первоисточника - об этом релизе не знал, думаю у ментора таких много. В больших конторах все-таки придерживаются заповедей Адама Смита - чтобы экономика работала, труд должен быть дифференцирован. Поэтому там есть chief-architect'ы, algorithm experts, rtl coders, verification architects, test writers и еще много ну совсем не универсального люда. И начальство специально следит, чтобы не просходило смешение обязанностей, ибо это херит exellence. Сравнивая результаты российской электроники и буржуйской по Адаму Смиту, приходишь к выводу, что он в чем-то был прав. Насчет производительности: не так давно видел отчет BDTI - они тестировали два HLS тула и получили результат синтеза, схожий с результатом ксайлиновских инженеров, делавших тоже ручками! Отчет по Synfora Отчет по AutoESL AutoPilot

Вот обоснованные тезисы от компании STMicro. Считаете там врут?

Так же плакали от смеха схематики в 90х... Будет сокрашение не рабочих мест, а зарплат

Ну допустим в этом посте автор наезжает на то что основательно перелопаченную версию VMM 2009.12 синопсис пометил минорным релизом 1.2 - я кстати тоже удивился, как основательно они перелопатив VMM, скромно отиндексировали это десятичной точкой. И то что они помучившись таки добавили class factory - это я тоже заметил. И разбили верификацию на фазы - тоже есть. И VMM1.2 нормально могла симулироваться только начиная с VCS 2009.12 :) Правда к единому базовом классу они так весь VMM и не подвели. Но видать на то есть основания. Хорошие вести! После усушки и утряски вертеть эти классы станет легче. Вот собственно официальный документ о конечных намерениях: создать common base class library (CBCL) и Universal Verification Methodology (UVM) на основе этой CBCL.

А что не так-то? H.264 кодер/декодер, 60GHz передатчик и image processor. Не верите в 60GHz приемопередатчики?

Немного мыслей по RTL дизайну и HDL языкам - может уже пора вспоминать С?

А синопсис съел CoWare. --- Крупные хищники хрустят костями.

Вот вчера посмотрел R2009b под win7x64 и порадовался - текущий MATLAB шустр и приятен. Хотя пару лет назад я был о нем такого же мнения. ИМХО это субъективное ощущение сильно зависит от железа, на котором MATLAB пускается - i7 c 4 гигами ему вполне приятен.

Схему с инверсным клоком для борьбы с метастабильностью современных триггеров использовать бессмысленно. Инверсный клок уже используется в схемотехнике D-триггера. Подав на второй триггер инверсный клок вы ничего хорошего не добьетесь. В аттаче описание классической двух-инверторной схемы КМОП-триггера по фронту. bookch8.pdf