[Rundll 0]

Я не могу понять, когда тактовый сигдал начинается с активного фронта, результаты неверны, хотя я ведь чётко описал, что чтение по восходящему фронту производить... Стоит только инвертировать сигнал CLK, на первый взгляд кажется правильные результаты или они и так правилны?... Что я напортачил?

[Golikov 0]

To Golikov A.

 

Я сейчас подготовлю скрины результатов моделирования, и скорее всего Вы сразу укажите, где я напортачил, т.к. такого не может быть, чтобы не работало за один такт (я уже сегодня даже со специалистом связывался и он мне тоже самое ответил)!

 

 

С уважением Никита

 

 

что то я вот сижу, смотрю, может у меня опыта маловато:)...

 

давайте по шагам

 

1 поставили адрес 0, поставили данные на дата_ин -> клок

1.1 после фронта на дата темп образовались данные которые лежат в ячейке 0

1.2 данные в ячейке 0 не равны данным дата_ин, и на ве появляется 1.

 

и того к следующему такту мы пришли с ве=1.

 

2. Меняются данные на дата_ин, и что должно тут произойти? тут начинается меняться ве, так как это асинхронный сигнал

2.1 задается новый адрес 1

2.2 клок, если ве не сменился то на дата темп попадают данные ячейки 1, а в ячейку 1 данные с дата ин, причем если дата ин появилось не вовремя, то и не совсем дата ин, а переходного процесса.

также возможна ситуация, что ВЕ успеет смениться за вновь поступившими данными на дата_ин, и ничего не запишется в 1 ячейку.

 

по мне это жутко не детерминированный процесс, и то что хоть когда-то это работает - это чудо:)...

 

почему может помочь работа по первому и второму фронту? ну хотя бы потому что второй фронт наступает до смены дата_ин, и ве потому зафиксирован, адрес также не меняется, и происходить запись того чего вы хотели по тому адресу по которому ждали... может в этом дело?

 

то что вы описали это не совсем компаратор за один клок, это кошмар какой-то:)...

сделайте хотя бы 2 цикловый конвейер. Первый такт выбирает данные и подготавливает результат, и все сохраняет в темповый регистры, а второй такт, все сохраненное в регистры пишет в память. Причем сохранять надо и адрес записи и все управляющие сигналы, это надо чтобы у вас на лету не менялась ситуация после выбора очередных данных, резко прибавит детерминизма, а скорость не уменьшит.

 

И еще, я бы все таки ве формировал как строб, то есть чтобы одним импульсом отмечался его фронт, а не тупо сигнал повисал в единице, не защелкнуто, и как флаг на ветру мельтешил за меняющимися данными.

 

кстати подумав еще немного, могу сказать что у вас за 1 клок ничего не выйдет в данной структуре.

надо либо научить память выдавать данные наружу без клока, либо научить ее сохранять их без клока, либо работать по 2 фронтам. При этом надо очень четко следить за адресом, а то если он смениться до 2 фронта, данные запишутся уже в новый адрес.

 

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

 

вот теперь совсем длинно

Изменено 28 июля, 2006 пользователем Golikov A.

[Rundll 0]

либо работать по 2 фронтам.

 

Так я и так описал двуфронтовую память!

По переднему фронту читаем, затем сравниваем и наконец по заднему записываем! Обычно компаратор реализуется на компонентах "xor" => сравнение не должно занимать много времени и we успеет сформироваться по приходу заднего фронта. Вы хотите сказать, что при относительно небольшой частоте он не успеет сформироваться???

[Rundll 0]

Я ещё разок всё внимательно перечитал... и кое-что подметил, в моей схеме не нужно дожидаться записи данных во второй блок ОЗУ! Ей необходимо только за один такт узнать есть ли данные в первом блоке ОЗУ, т.е. я спокойно могу загружать новые данные во втором такте, одновременно с записью данных во второй блок ОЗУ... опять же вот Вам конвейер :) Может вы это и имели ввиду, т.к. действительно при этом трюке будет необходима вторая шина адреса, т.к. одна из них в любой момент времени всегда будет занята либо записью, либо чтением.

 

Так ещё раз составляю картину происходящего, а Вы оцениваете :)

 

1. Такт (устройство готово к приёму данных ready_device<='1') загружаем символ в регистр, в этом же регистре происходит небольшая логика по вычислению хеш-адреса ОЗУ.

2. Выставляем сигнал ready_device в '0' начинаем обработку данных, читаем сформированный адрес из регистра и выдаем данные из памяти по заднему фронту (!) за оставшиеся пол-такта производим сравнение, так к следующему восходящему фронту, который в свою очередь будет являться промежутком для записи данных в память, мы имеем сформированный сигнал we!

3. Открываем ready_device, загружаем символ в регистр, там производим небольшую логику на основании сигнала we и одновременно за этот такт пишем в оба блока ОЗУ..... Хм тогда нам не нужна вторая шина адреса

4. Цикл повторяется заново

 

Итог, как не крути полюбому необходимо минимум 2 такта для полной обработки, т.к. мы ранее не учитывали буфферный регистр для приёма и выч. небольшой логики над информацией. Как Вам такой вариант? Он рабочий или нет? Кстати на формирование установку и формирование we будет отводится целый такт (пол-такта заднего фронта первого такта и пол-такта переднего фронта второго) Я ещё раз обращаю Ваше внимание, что чтение данных производится не по переднему фронту, а по заднему, а запись по переднему! Только что моделировал такой вариант - работает превосходно! или всё же есть риск? Как такое описание повлияет на частоту устройства?

 

P.S. Чем Вам не понравилось описание компаратора? Вы знаете другой способ описания компаратора, кроме низкоуровнего на лог. элементах? :)

Изменено 28 июля, 2006 пользователем Rundll

[Rundll 0]

Кстати, ко всему прочему, можно затриггерить компаратор! Теперь данные взятые по адресу из ячейки ОЗУ по нисходящему фронту будет сравниваться и стабильно выравниваться перед приходом переднего фронта, таким образом мы получили абсолютно синхронную схему и write enable не будет вести себя как ему угодно! Я конечно могу ошибаться, поправляйте, я буду только рад!

[Rundll 0]

Рад Всех привествовать на вновь функционирующем форуме!!!!!!! Очень обидно конечно, что так получилось всё резко.... Никто не ожидал, но что есть, того не миновать, как говорится!

Ну что ж можно собственно приступить к ЛЮБИМОЙ работе !!!!

 

Я вижу, что пост был дегродирован.... удалено 3 страницы :((( Очень сильно обидно, что в день взлома, я ждал ответа от товарища Golikova A. по поводу разрешения проблем и рекомендаций моего проекта. Ну что ж придётся начинать всё сначала :)

 

Ребята, очень срочно жжёт следующая ситуация:

 

нуждаюсь чисто в рекомендациях, советах и т.д.

 

Разработан блок компрессии/декомпрессии данных. Пропускная способность 400 Мбит/с, компрессия, декомпрессия универсального вида данных, сущ. множество необходимых generic-параметризуемых параметров для различных ПЛИС и заказных СБИС, адаптивность кодов и т.д.

Собственно интересующие вопросы к специалистам:

 

Есть два блока ОЗУ с граничными параметрами (от 4096х20- до 65536х24 и более, если конечно позволяет СБИС и второй блок - 4096х12 по 65536х16 и также более)... Короче, шина адреса и сигнал "write enable" для обеих ОЗУ одинаковы! Между двумя ОЗУ стоит компаратор, разрядность которого определяется разрядностью данных первого блока ОЗУ! Компаратор служит для управления сигналом "write enable". Требование к функциональным возможностям системы: по приходу данных и адреса в первый блок ОЗУ, по этому адресу выбираются необходимые данные, затем сравниваются (в компараторе) с данными пришедшими в этот блок ОЗУ. Если такие данные существуют в первом блоке ОЗУ, тогда необходимость проводить какие-либо изменеия исключена, наоборот, если данные не найдены, по этому адресу ОЗУ, перезаписать их, а также записать во второй блок необходимую информацию по этому адресу! Впринципе алгоритм очень прост и уже реализован..... Хм... только в 3 такта машинной реализации!!!

 

1. Читаем адрес, выводим данные

2. Сравниваем

3. По мере необходимости пишем

 

Вопрос: возможно ли модифицировать блок таким образом, чтобы система уменьшила число тактов на обработку данного, элементарного алгоритма?На данный момент актуальными были следующие предложения, т.к. система практически не конвейеризуема (кроме отдельных блоков, что я и сделал), я услышал след. 1-3 реальных (подходящих мне) заявления:

 

1) Реализовать по технологии PLL (предложение товарища Maksya), увы отказано заказчиком :( сразу! Хотя мне это очень понравилось, подробно изучил, пытался реализовать пока не сказали ,что нам такой девайс не нужен :( (Maksya, не обижайтесь, мне всё-равно Ваше предложение нравится! Свежее, актуальное, современное... не знаю чем не понравилось....)

 

2) Реализовать устройство по технологии DDR (двухфронтовая синхронизация) причём по передниму фронту активизируем чтение, затем производим сравнение, а потом по заднему фронту пишем! По поводу этого предложения есть отдельные замечания, которые мне не очень нравятся, именно потому, что они практически не реализуемы, ИМХО! Одни говорят, что компаратор это быстрейшее из устройств, другие наоборот... В любом случае, я изучал цифровую схемотехику, где компаратор реализуется на элементах "И" хотя ИМХО, предподчтительнее "xor", ему необхдимо (относительно данной разрядности) в стиле конвейерного сравнителя каждого бита лог. операцией "И", выполнять операции над след. решением.... Естественно не трудно подсчитать, что задержка (в моём случае минимум в 20 разрядном корпараторе) сотставит товарищи...Хм... имхо опять же, приличное физичиское число! Т.к. сначала 10х10 каждый бит по "И", затем 5x5 решений по "И", хм..., а дальше чуть сложнее! А если разрядность будет расти? Представляете задержку между активным и пассивным фронтом... Уххх..! имхо не успеет сформировать сигнал "we", увы :( Даже моделировать (пост-синтез) пробовал, косяк всё-равно!

 

3) Чисто моя реализация.... Стоит контроллер, который управляет отдельными блоками системы, т.к. система не конвейеризуема по своей сути и реализации, и описал систему таким образом, что все её блоки синхронны включая компаратор , т.е. грубо говоря, напичкано регистров на каждом выходе отдельного асинхронного блока. Контроллер заправляет тем, что упровляет тем, когда шина данных свободна для приёма новой информации, когда занята, а так же какой из блоков системы в данный момент должен быть активизирован (Не забывайте друзья, что в системе ещё находится куча блоков, с которыми я более менее справился и сейчас во внимание не беру! Т.е. проблема чисто в отдельном блоке!) Контроллер - красивое название неправда ли :) Допустим в моей системе Я называю основным контроллеромм (плиз, только унижайте :) ) простейшее устройство, которое представляет собой 4-х разрядный, циклически сдвиговый регистр. Каждый отдельный бит разряда, соответствует разрешению работы отдельного блока (причём, не обязательно в последовательной работе! Блоки могут включатся как им укажет ядро контроллера )... многие могут со мной не согласиться, мол можно и без него, но увы... нужно! Например компаратор не знает чего ему сравнивать в данный момент времени, и какие данные именно... и т.д. ну и как говорят, одну задачу 1000 программистов решит по разному и спорить можно только по эффективности реализации!

 

Так же было ещё нескольких предложений, но почему-то я посчитал их аутсайдерами (хотя может и не прав!)

 

Уважаемые специалисты, пожалуйста помогите разобраться в данной ситуации! Принимаю во внимание любые ваши предложения! Всё это очень интерестно и занимательно! Нуждаюсь в срочной помощи, т.к. проект стоит в ожидании "приговора"!

 

Благодарю Всех, кто обратил внимание и прочитал мой топик!

 

С нетерпением жду все отзывы, рекомендации и предложения!!!

 

Заранее простите за допущенные мною, как орфографмческие, так и технически абсурдные высказывания и ошибки в теме! Студент, учусь, с удовльствием набираюсь опыта, так уж простите :)!!!

 

С уважением, Никита!

 

 

 

Уважаемые админы и пользователи электроникс.ру. Прошу не ругаться за флуд! На момент написания поста, всё было иначе, кто-знал :)

Изменено 1 августа, 2006 пользователем Rundll

[Golikov 0]

С нетерпением жду все отзывы, рекомендации и предложения!!!

 

 

Я за контроллер! Если я правильно понял суть то у вас несколько блоков, через которые проходят данные от входа до финального результата. И ваш контроллер просто говорит в какой момент какой блок работает. Если это так, то я за контроллер. Но! не как финальный вариант, а как за способ попробовать первый рабочий вариант. Потому что потом такую систему можно более гибко видоизменять, и в конце придти к нормальному конвейеру, где каждый блок выдает данные за такт или максимально ускорить, убрав ненужные задержки времени между блоками. Почему то мне вот сейчас со стороны кажется, что это должно получиться, второе то точно должно.

Должно, но позже, а сейчас делайте контроллер, и гоняйте систему, выясните характеристики, найдите конкурентов. Лично я думаю, что это очень важный этап, совершенствовать можно бесконечно, рынок, заказчики все это уйдет до того как вы сделаете само совершенство, важно столбить результаты!

[Rundll 0]

Я за контроллер!

 

Благодарю за поддержку моего предложения! Вы реально придали мне уверенности! :)

 

И ваш контроллер просто говорит в какой момент какой блок работает

 

Совершенно верно! Без контроллера устройство на данный момент реализации просто будет не правильно функционировать... Например компаратор, на очередном такте работы устройства, может продолжать выдавать результаты сравнения предыдущих... т.е. если данные в пред. шаге не были найдены, тогда откроется WE, по идее всё верно...Но единица то на выхорде останется пока не придут новые данные! Т.е. получится ситуация, что новые данные могут перезаписаться по адресу ОЗУ, предварительно, не попав на обработку компаратора! Вобщем, очень простое, по своей сути и реализации устройство, выполняет жизненно необходимую для устройства функцию!

 

выясните характеристики, найдите конкурентов

 

честно, конкурентов не искал :) их очень много ИМХО, т.к. алгоритмов кодеков огромная куча! Причём для различных типов данных, отдельный специализированный вариант реализации может выдавать нехилые отношения, соревноваться с которыми, универсальный вариант реализации, не сможет подавно! Да и к тому же, я обычный студент первого курса радиотехнического универа, кому я нужен со своим кодеком :) Это прежде всего, чисто работа для повышения своего опыта и уровня, плюс, получение огромного удовольствия от дела! Единственное? что на данный момент мне известно, это то, что товарищ T.Weltch в 1984 году, впервые разработал такой девайс, причём поддерживая частоту 15 МГц, устройство способно было обрабатывать 3- 7,5 Мб/с, в зависимости от количества встречаемых коллизий адресов ОЗУ... Вобщем нехило для тех времён...!

 

А вобще, я с Вами абсолютно согласен! Необходимо погонять систему такой какая она есть на данный момент и потихоньку её модифицировать. В любом случае, кстати, можно будет в параметре синтеза оставить значения, для выбора пользователем, какую реализацию устройства ему юзать! Тоже дело! И старую реализацию можно будет не трогать (допустим, ИМХО, для старых девайсов типа FLEX 10KE и др., наилудшим вариантом будет только 4-х тактовый )... Пусть пользователь выбирает, а система подключает необходимый по технологии блок!

 

Спасибо большое за помощь, поддержку и предложения!

 

С уважением, Никита!