dxp

Все есть. Дока версии 2.0, ревизия 22, страница 25. Естественно, что семафор легче канала. Но у него и функциональность другая. Их нельзя сравнивать. Если реализовать ту же функциональность - т.е. кольцевой буфер (фифо) на основе семафора, то и получится где-то так же, если не хуже. В версии 2, кстати, лучше уже не юзать TChannel (а MemoryManager'а там вообще нет - не нужен он стал при наличие подержки шаблонов). Есть шаблон channel, на нем все прекрасно реализуется и пользоваться им проще и безопаснее. Единственно, что надо помнить - это то, что на шаблонах очень легко и просто нагенерить горы кода. Поэтому тут надо прявлять осмотрительность (в частности, не городить каналы на объекты типов со значительным размером - ведь проталкиваение через канал производится путем копирования. Тут накладные расходы на копирование могут быть весьма неслабыми).

Блин. Нет такого в доке. Есть. :) Надо бы уточнить, что Вы понимаете под термином "семафар". Мутекс - семфор. И флаг события тоже семафор. Нет счетных семафоров? Да, нету. А они нужны? Приведите реальный пример на мелкой однокристаллке, где они нужны. Типа: Ну конечно они дураки, а мы умней <{POST_SNAPBACK}> А что, не так, что-ли? AVR (ядро) по некоторым данным разработатли два студента из Норвегии. И задумка у них неплохая была, но вот реализация подкачала. Вот этот самый указатель стека - совершенно убогий! Ведь именно из-за этого IAR городит отдельный стек для данных. Два стека - это криво, преимуществ никаких, одни недостатки. А ведь будь указатель стека нормальный, то и не было бы никакой необходимости в отдельном стеке данных. Для стека данных нужно, чтобы указатель стека поддерживал расширенные режимы адресации (со смещениями) и адресную арифметику. Т.е. по-нормальному указатель стека должен быть регистровой парой. А в таком виде, как он есть - отстой. Второй момент. У AVR слишком дофига регистров при том, что работа с ними неортогональна (младшая половина не работает, например, с константами). Гораздо лучше было бы если бы было регистров вдвое меньше (16), но все они были одинаковы и все они могли образовывать регистровые пары при адресации (т.е. быть указателями) и при адресной арифметике. Анализ кода показал, что в AVR заметный оверхед на пересылках адресов между регистрами, а нормальных поинтеров только два (из которых один отдан по указатель стека - Y). Реально в программе доступен только один Z, а X - недоделанный, не поддерживает адресацию со смещением. Вся эта кривизна очень распрекрасно видна при сравнении, например, с MSP430. Третий момент - работа с памятью. Она медленная. Для Load/Store архитектуры работа с памятью должна быть максимально быстрой - ведь это ключевой момент, определящий быстродействие. Два такта на одно обращение - никуда не годится. Элементарный инкремент переменной в памяти занимает 5 тактов. из которых 4 - это накладные расходы на пересылку. Никуда не годится! Это только основные моменты, но они, имхо, определяющие. Недоделанный он, AVR этот.

SVN. Раньше пользовался CVS, но как только познакомился с SVN, сразу перелез на нее. SVN рулит!!! Хотя речь не столько о HDL идет, сколько о программинге и вообще.

Послушайте, я не для того чтобы поболтать какой пакет лучше. К сожалению я завершил уже вторую неудачную попытку за последний год развести плату в Pcad2002. Проходит месяц и я понимаю что это не возможно. Приходится возвращаться в Pcad4.5, несмотря на то, что необходимо по новой создавать для проэкта схему и библиотеку. Для меня очень серьезный вопрос что использовать в дальнейшем вместо Pcad4.5. <{POST_SNAPBACK}> Protel DXP2004 весьма дружественный к пользователю пакет. Не скажу, что там все просто, но, имхо, интерфейс там очень простой и интуитивно понятный. Есть уроки на русском языке от Ю.Потапова. Ручная разводка тоже на высоте. Единственное, чего мне не хватает в ней, так это задавать area rules и возможности таскать шины. Все остальное там весьма прилично, начиная от look-ahead трассировки и заканчивая стековой моделью процессов, т.е. когда можно начать новое действие, не прерывая текущего (а текущее при этом как бы в стек проталкивается), а потом закончить новое - прежнее из стека вывалится в той же точке, где его прервали. Очень удобно. Удобно, на мой взгляд, сделана система синхронизации безо всяких этих ECO, на основе уникальных ИД компонетов. Есть возможность многоканального дизайна - когда одинаковые куски на схеме в плате можно быстро растиражировать. Основной недостаток, имхо - это требовательность к компу. Жручая до памяти прога. Но работать вполне уже можно и на 256 мегах, тут много зависит от того, какой дизайн сам по себе по объему. Что касается Пикада 200х, то в нем нет абсолютно ничго от старого досового 4.5 за исключением названия. Пикад 200х - это продолжение линейки Танго от фирмы Accel Technologies, которая пикад купила в свое время. Т.ч. ни приемственности, ни идеоглогии, имхо, там нет. А ручная трассировка все же в Протеле удобнее несказанно! :)

Я ни секунды и не сомневался в том, что мне нужна статика. Более того, статика сейчас и используется. Только она асинхронная. Накувыркался с ней, теперь хочу синхронную поставить. Если посмотреть начало темы, то можно увидеть, что никакие динамические памяти я даже не рассматривал и, более того, наоборот вступил в спор с предлагающими делать на ней. И сам исходный вопрос содержал прямо и название микросхемы синхронной статической памяти 1Мх18. Да, спасибо, я в курсе. Но мне этот такт не критичен. Видимо, на Flow-through и остановлюсь.

Кстати, объясните, кто знает, тонкую разницу между сигналами ADSP и ADSC (за исключением того, что ASDP приоритетнее). Зачем их два? И накой там этот burst режим, если внутренний счетик всего на два бита. Все равно максимум через четыре обращения надо новый адрес метать. В чем глубокий смысл?

Вот этот вопрос меня и интересовал больше всего. Но одно дело, когда на каждое обращение два такта, другое - когда просто задержка на такт или два. Т.е. выставил адрес, данные идут с задержкой. Но в это время уже можно следующий адрес пихать. Произвольный. Коль скоро это так, то и тормозов нет почти - один или два такта на блок - это копейки.

Вот теперь понял, что вы имеете в виду. Ок, считаем. При использовании быстрой SDRAM имеем 9 тактов на запись из 4-х слов. Итого, наши 4 столбика запишутся за время (возьмем тактовую 100 МГц) 9*288*10нс = 25920 нс или 25.92 мкс. При пересчете на один столбец - 25.92/4 = 6.48 мкс. А на SRAM при этой же тактовой я получаю 2.88 мкс. Более, чем в два раза. При вашем подходе я еще должен выделить буфер внутри под 4 столбца (18 кбит, как вы указали), только реально там должно быть два таких буфера - пока один заполняется, другой заливается во внешнюю память. Либо иметь 4 фифо - на каждый столбец. В принципе, это несложно. А ПЛИСка у меня не второй Циклон (которых реально еще, можно сказать, нет и которые только в коммерческом диапазоне температур, а мне надо индастриал), а EP1C6, где памяти всего 92 кбита. Жирновато получается. В общем, по всем пунктам на динамической памяти это решение выходит хуже: и сложнее, и толще, и геморройнее. Универсальности, как раз, тут нет - универсальность на статической. А расширяемость тут гарантировано не нужна.

Не понял. Как это поколонно? Как это инкрементировать RAS при постоянном CAS? Если метнуть команду RAS, то после нее надо метать и CAS. Сколько это времени займет? И причем тут фифо? Я привел пример. Вопрос из него: за сколько времени можно записать DRAM столбик из 288 слов? В чем универсальность? И про какую расширяемость вы говорите? Я пока что вижу просто неслабое усложнение (со статической памятью работать попроще будет особенно если сравнивать с DDR) при сомнительном результате. Ширина слова 16 бит (даже 14 - разрядность АЦП).

Да не потребуется там никаких мегагерцев!!! Поток данных там известен - полтора десятка мегаслов в секунду, он НЕ ИЗМЕНИТСЯ. Это определяется САМОЙ ДОРОГОСТОЯЩЕЙ И УНИКАЛЬНОЙ ДЕТАЛЬЮ прибора - КРТ охлаждаемым фотоприемником! Под него и сканер сделан (там даже два сканера - строчный и кадровый), и оптика (германиевая). И ничего это меняться в обозримом будущем (по кр. мере еще лет 10) точно не будет - не та это область, где каждые полгода новая технология начинает рулить. Согласитесь, пропускная способность памяти - это не единственная ее харатктерискика, раз, и кое-где не самая главная, два. Мне достаточно 100 МГц, но нужен произвольный доступ. SDRAM в системе тоже предполагается, но в несколько другом месте (на процессорной шине). И там, в частности, для увеличения скорости обработки сигнала по столбцам как вариант предполагается и заливка повернутого кадра. Но для первичного преобразования формата нужна обычная память с произвольным доступом, а чтобы при этом еще и скорость иметь приличную (и отсутствие геморроя с задержками в ПЛИС) предполагается использовать синхронную память. Вот и все. Я уже устал твердить, что не пропускная способность меня ограничивает, не поток данных. А ФУНКЦИОНАЛЬНОСТЬ памяти... Хорошо. Вот Вам пример. Мне надо записать числа 1, 2, 3.., 287 по адресам 0, 768, 2*768, 3*768.., 287*768 соответственно. За максимально короткое время. Меня бы устроило 10 нс * 288 = 2.88 мкс. За сколько Вы запишете этот блок по этим адресам на вашей мегапамяти?

Не понял. Вот приходит от сканера синхросигнал фрейма, по нему я вычитываю из ФПУ 288 слов-данных. Их нужно записать столбиком. Куда их писать, если нет произвольного доступа? В строку? А потом медленно и долго переформатировать? А следующий кадр? А через 19 мкс приходит следующий синхросигнал. И получаем новый столбик. И так они и валятся пока зеркало не сделает развертку полного кадра. 768 столбиков. Записывая данные последовательно, получим повернутый кадр. А его надо тут же выдавать наружу, на монитор. В телевизионном формате. По строкам, т.е. чересстрочно. И как быть? Геморроя тут я особого не вижу. Геморрой был с асинхронной памятью. Большой объем мне не нужен - полный кадр занимает порядка 442 килослова. И стоимость всей комплектухи просто меркнет перед стоимостью фотоприемника - вот под него и приходится постраиваться. Меня просто исходно насторожило наличие режима burst, не было уверенности, что с этой памятью можно на каждом периоде клока метать данные по произвольным адресам. Но вот коллеги, вроде, утверждают, что все должно быть хоккей. :) Скачал модель, буду пробовать.

Смотрите здесь: http://xgoogle.xilinx.com/search?btnG=Goog...t2=Search&site= <{POST_SNAPBACK}> Посмотрел на qdr. Насколько понял, там просто упор на пропускную способность. В смысле произвольного доступа она точно такая же, как и статическая синхронная. А пропускной способности хватает и так. С чем Вы согласны? То, что предлагается, вообще по требованиям функциональности не подходит. А что касается стоимости, то уже наличие такой сложной и недешевой приблуды, как прецизионный быстродействующий электромеханический сканер уже указывает на то, что сотня баксов рояли не играют. Фотоприемник, к слову, стОит такие пятаки, что там все остальное просто шум.

Сдаеться мне, что тут выбрано не совсем правильное направление, а именно предполагаеться укладка кадра в память "в лоб". ИМХО стоит все таки обдумать другую упаковку кадра в память, которая позволит использовать потоковую запись в память и при этом случайое позиционирование. ЗЫ. можно транспонировать кадр на "лету" используя фифо. Правда размер фмфо нужно будет уточнить <{POST_SNAPBACK}> Сдается мне, что неправильно Вам сдается. :) Представьте: линейчатый фотоприемник (линейка) стоит вертикально в поле зрения прибора. Перед объективом стоит зеркало, которое позиционируется с помощью сканера - таким образом производится развертка изображения. Данные поступают по вертикали (столбиками), и укладываются в память. После полного прохода зеркала формируется кадр. Выдается кадр наружу уже как принято - по строкам. И что вы тут придумаете? Фотоприемник такой - он специально рассчитан на такую схему считывания. Кроме того, внутри него еще и ВЗН (временная задержка и накопление) реализовано, т.ч. способ формирования изображения тут даже не обсуждается. Все это замечательно работает в текущем варианте. Только память, как уже сказал, используется асинхронная, из-за чего имеется приличное количество геморроя, от которого хотелось бы избавиться в следующем варианте. Помимо всего этого просто есть необходиость считать, например, небольшой прямоугольный фрагмент или записать его туда. Словом, нужен быстрый произвольный доступ.

А если позвать на помошь функцию транспонирования ? ну обзовите ряд - "столбиком" и пишите <{POST_SNAPBACK}> :) Дык когда кадр сформирован, его надо наружу выдавать. И уже по-человечески, по строкам. :) Кроме того, формирование кадра - это частная задача. Еще надо быстро работать с произвольными фрагментами кадра, а для этого тоже нужен быстрый произвольный доступ. А вообще, что такая экзотическая задача, что-ли? Скорость не феноменальная. Объем тоже достижимый. Надо-то всего-то чтобы память была синхронной и по клоку работала. Примерно, как внутри тех же альтеровских ПЛИСин, только проще - два порта не надо.

Ну возьмите QDR. <{POST_SNAPBACK}> А что это такое? Где посмотреть? Именно! Да не в потоке дело! У меня данные, в частности, поступают с линейчатого фотоприемника - т.е. столбец считывается. И надо их так и писать столбиком в память - чтобы кадр сформировать. Т.е. идет блок 288 слов данных, надо их прописать по адресам 0, 1*768, 2*768, 3*768.., 287*768. Каждое слово за такт. SDRAM не дает произвольного доступа без потери скорости.

Дело в не том, сколько он там будет лежать. Дело в том, что требуется обращение к произвольному адресу на КАЖДОМ такте. А SDRAM, afaik, может бодро только по последовательным адресам метать.

В проекте на ПЛИС используется аснихронная память. Минусы очевидны: проект синхронный, для работы с асинхронной памятью приходится городить задержки, из-за чего для достижения скорости приходится задирать тактовую частоту (которая, в общем-то, может быть не слишком высокой для решения всех остальных задач), результирующая скорость все равно невысока, усложняется контроллер памяти и т.д. Требуемый объем - 1М слов (16 бит). Комфортная тактовая на ПЛИС - 100 МГц. (В текущем проекте тактовая 160 МГц, память асинхронная самсунговская на 10 нс, цикл обращения получается 3 такта - 6.25нс * 3 = 18.75нс. Не фонтан :( ) Разумным решением, вроде бы, является использование синхронной памяти. Посмотрел у Cypress и IDT. Есть ряд вопросов. У Cypress подходящими выглядят CY7C1382C (1Mx18 Pipelined SRAM) и CY7C1383C (1Mx18 Flow-Through SRAM). Микрухи похожи очень, насколько понял, отличие только в том, что у pipelined выход с памяти идет через регистр, поэтому задержка на такт, но зато можно тактовую более высокую гонять. Поправьте, если ошибаюсь. А главная непонятка следующая: не понял толком, возможо ли там обращение по произвольным адресам на каждом такте. Это очень важно для разрабатываемого устройства - требуется записывать поток по произвольным адресам (формировать кадр). Из диаграммы в даташите следует, что там идет загрузка адреса, потом уже данные пишутся или читаются, и приводится диаграмма для т.н. burst режима, когда внутренний счетчик адреса инкрементит. А нельзя ли просто на каждом такте новый адрес метать? И, кстати, не совсем понял смысл того, что счетчик этот внутренний всего 2-битный, т.е. через 4 обращения надо все равно новый адрес грузить. Зачем весь этот огород, что это дает? В общем, кто имеет реальный опыт, посоветуйте/отсоветуйте? Надо просто иметь снаружи ПЛИС хранилище данных на 1 мегаслово с возможностью писать и читать со скоростью 100 Мслов в секунду, т.е. при 100 МГц тактовой. Это, ессно, при обращениях блоком, задержки на загрузку адреса и переключение шины данных тут не принимаются во внимание. И чтобы, хоть обращение и блоком идет от 64 до 256 слов, можно писать/читать каждое слово по произвольному адресу. Подходит ли для данной задачи, например, CY7C1383C?

Условная компиляция. Если М определено, то будет компилироватся первое выражение. Если нет, то второе. #0 означает задаежку. Вообще-то, лучше бы Вам взять книжку какую-нить по Верилогу почитать - все такие вопросы сами отпадут.

На фтп лежит, вроде, полная, только ее отличие от триала в наличии библиотек от производителей, которые, в общем, не нужны - их надо брать из пакетов от производителей. Из-за них полная версия и толстая. Я делал, как рекомендовали - триал и лечение.

У них есть куча примеров. На асме и на С. Смотреть здесь. http://focus.ti.com/mcu/docs/generalconten...430_desres_code Сложного ничего нет. Но по сравнению с, например, AVR'овской EEPROM несколько муторно. Ну, и необходимость данные организовывать в блок, т.к. отдельную ячейку так просто не изменишь - одна ячейка не стирается, надо весь блок тереть.

6.3 не отсюда тянут, а с сайта Альдека. Там у них триальная версия. На нее ставится сервиспак (сегодня уже второй), который тоже с сайта тянется. А лекарство и тут, и на Телесистемах в конфе по FPGA отыскивается без труда.

А что, продукт не леченный? И вообще лучше уже пользоваться версией 6.3. Она и глюков меньше имеет, и работает симулятор в ней гораздо быстрее. Где взять, как поставить - поищите на форуме, не так давно этот вопрос подробно обсуждался.

И EEPROM, и FLASH - это электрически стираемая программируемя ПЗУ, что явно следует из первой аббревиатуры. Слово FLASH ввел в свое время Intel, один из тех, кто стоял у истоков этого. Это было чем-то вроде торговой марки, но термин был бодро подхвачен и получил популярность. По сути принципиальное отличие EEPROM от FLASH состоит в том, что EEPROM имеет возможность стирания отдельных ячеек, а FLASH - только блоком. Из-за этого ячейка у FLASH более компактная и дешевая. Ресурс и время обращения - это уже частные моменты, они сильно разнятся от производителя к производителю. Например, интеловская флешь 28Fxxx имела ресурс 1е6, а у Атмела в AVR'ах всего 1000 циклов. И у того же Атмела в датафлешах, afair, 50000 до необходимой регенерации, а после нее еще столько же и т.д. А у ТИ в MSP430 типовое количество циклов 1е4. А время записи ячейки у AVR составляет единицы миллисекунд, а у MSP430 (специально замерял) порядка 125 мкс. Естественно, что в МК EEPROM стремятся сделать с как можно бОльшим количеством циклов. Для флеши в МК этого просто не нужно.

Ну вот, так и есть. Это, насколько понял, глюк этой версии. Проявляется в С++ режиме. На работоспособности, вроде, не сказывается.

Это не к IAR'у относится, а к языку. В языках С/С++ нет двоичного представления. Наиболее близкое - шестнадцатеричное, пишется с префиксом 0x. Вроде нет. Я оболочкой их вообще не пользуюсь - внешний мощный редактор + система сборки проекта на основе make. Чего и Вам желаю. Кстати, редактор можно там и внешний указать, только вот переход на строку с ошибкой при этом, afaik, не работает. Да, это можно, но только в режиме ++, т.к. аргументы по умолчанию - это плюсатая фича. Возможно где-то что-то еще не включено. Там надо тип библиотеки указать, если его указать clib, то он и синтаксис плюсовый не позволяет использовать.