[Rundll 0]

А в Вашем случае вычисление в несколько тактов необходимо? Если операция (в примере это /) не требует памяти, а является комбинационной, то ее можно вычислить за один такт. И следовательно она легко заталкивается в конвейер. Вопрос только в длительности этого такта.

 

Хеширование, поиск по ОЗУ, сравнение, счётчики, инициализаторы... как я уже говорил ОЗУ на базе 2-х блоков 20 и 14 разрядных данных по 16384 адресов в каждом (играют роль ассоциативного массива в системе), за один такт никак не получится это реализовать, но доделывать логику в след. такте никто не запрещает, я сейчас работаю как раз над реализацией этой идеи, посмотрим что выйдет :)

[Golikov 0]

А в Вашем случае вычисление в несколько тактов необходимо? Если операция (в примере это /) не требует памяти, а является комбинационной, то ее можно вычислить за один такт. И следовательно она легко заталкивается в конвейер. Вопрос только в длительности этого такта.

 

Хеширование, поиск по ОЗУ, сравнение, счётчики, инициализаторы... как я уже говорил ОЗУ на базе 2-х блоков 20 и 14 разрядных данных по 16384 адресов в каждом (играют роль ассоциативного массива в системе), за один такт никак не получится это реализовать, но доделывать логику в след. такте никто не запрещает, я сейчас работаю как раз над реализацией этой идеи, посмотрим что выйдет :)

 

 

Я может ошибаюсь но по моему вашу задачу можно разбить на много элементарных, и конвейеризовать их... Хотя надо детальнее в алгоритме разбираться, конечно, для таких заявлений%)... Удачи вам.

[Rundll 0]

Дабы не мусорить на форуме и не создавать новых тем, решил отписаться в свою старую (впринципе вопрос тот-же :))

 

Ребята, возник у меня следующий вопросик к вам:

 

сначала ещё раз вкратце опишу систему, а потом задам :)

 

имеется два блока ОЗУ, причём шина адреса и сигнал write enable одни на двоих. За управление сигналом write enable отвечает компаратор. Если данные, взятые по определённому адресу на выходе первого блока ОЗУ и данные пришедшие совершенно из другой системы не равны, компаратор выдаёт '1' , write enable открывается и происходит перезапись данных как в первом так и во втором блоке... Почему-то я решил эту задачу так, что она выполняется за 3 такта, т.е. 1 такт - берём данные по необходимому адресу памяти, 2 такт - сравниваем их, 3 такт если необходимо перезаписываем. Собственно вопрос: упорол ли я косяка в том, что описал синхронный компаратор работающий по клоку, как я правильно понимаю, это уже не просто компаратор, а плюс ещё и регистр. Объясните плиз, будет ли правильно работать устройство если я поставлю асинхронную логику между двумя синхронными, на сколько при этом упадёт частота тактирования (была 157 МГц) или же я и так всё правильно сделал :) Вопрос номер два: поясните пожалуйста что предпочтительнее синхронный или асинхронный сброс устройства и почему?

[CaPpuCcino 0]

Вопрос номер два: поясните пожалуйста что предпочтительнее синхронный или асинхронный сброс устройства и почему?

C.Cummings "Synchronous Resets? Asynchronous Resets? I am so confused! How will I ever know which to use?", "Asynchronous & Synchronous Reset Design Techniques - Part Deux" :

http://www.sunburst-design.com/papers/

[Golikov 0]

Дабы не мусорить на форуме и не создавать новых тем, решил отписаться в свою старую (впринципе вопрос тот-же :))

 

Ребята, возник у меня следующий вопросик к вам:

 

сначала ещё раз вкратце опишу систему, а потом задам :)

 

имеется два блока ОЗУ, причём шина адреса и сигнал write enable одни на двоих. За управление сигналом write enable отвечает компаратор. Если данные, взятые по определённому адресу на выходе первого блока ОЗУ и данные пришедшие совершенно из другой системы не равны, компаратор выдаёт '1' , write enable открывается и происходит перезапись данных как в первом так и во втором блоке... Почему-то я решил эту задачу так, что она выполняется за 3 такта, т.е. 1 такт - берём данные по необходимому адресу памяти, 2 такт - сравниваем их, 3 такт если необходимо перезаписываем. Собственно вопрос: упорол ли я косяка в том, что описал синхронный компаратор работающий по клоку, как я правильно понимаю, это уже не просто компаратор, а плюс ещё и регистр. Объясните плиз, будет ли правильно работать устройство если я поставлю асинхронную логику между двумя синхронными, на сколько при этом упадёт частота тактирования (была 157 МГц) или же я и так всё правильно сделал :) Вопрос номер два: поясните пожалуйста что предпочтительнее синхронный или асинхронный сброс устройства и почему?

 

 

вопрос номер 1.

можно было и в один такт, только при этом частота упадет.

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

У меня добавление сравнения данных перед записью на спартане 3 роняло частоту со 170 до 109 МГц, но это все очень относительно. Так что точнее вам только симулятор скажет.

 

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

 

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

 

вопрос номер 2.

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

 

 

 

надеюсь не слишком длинно...

[Rundll 0]

To Golikov A.

 

Благодарю Вас за столь подробный ответ!

 

Понимаете, для меня очень важен именно тот факт, что чем меньше тактов тратит устройство для обработки одного цикла, тем лучше! Да вы правы, я сделал конвейер внутри системы, но данные на входе задерживаются на столько тактов, сколько затрачивается на один цикл обработки данных, иначе никак нельзя, т.к. устройство узнаёт что ему делать со следующими данными только после завершения операций над первыми.... Меня не устраивает результат своей работы, т.к. при частоте ~ 160 МГц устройство тратит на один цикл 4 такта, т.е. оно обрабатывает 40 миллионов слов в секунду... Вы говорите что можно было всё в один такт пихнуть, но даже если частота упадёт до 100 или 80 Мгц, то это 100 и 80 миллионов слов в сек. соответственно!!! Результат заставляет задуматься....

 

Кстати я как-то вначале пробовал делать устройство так, чтобы оно за один такт выполняло весь цикл, но моделирование мне выдало такие результаты, что я забросил это дело :) (Синтез проводил в Leonardo Spectrum, моделировал в MAX PLUS II.... на частоте 10МГц !!!! почему такие результаты, ума не приложу)

 

To CaPpuCcino

 

Спасибо за предоставленную информацию, сейчас почитаю.

[Rundll 0]

Прошу прощения за флуд...

 

У меня возникли попутно ещё несколько вопросов.

 

To Golikov A.

 

Скажите, а даже если и получится всё в один такт запихнуть, Вы можете примерно оценить, на сколько будет падать частота при увеличении разрядности данных? В данный момент в ЦУ стоит 2 блока ОЗУ (4096х20 и 4096х12) и 20-ти разрядный компаратор. Хотя для достижения максимальной эффективности работы устройства предполагается использовать другую конфигурацию: ОЗУ (65536х24 и 65536х16) между ними 24-х разрядный компаратор. Только что протестировал свою систему (с 4-х ступенчатым конвейером), при таких параметрах частота упала со 157МГц до 145 МГц. Хм.. я считаю, что это норм, интересно какова была бы разность частот в однотактовом ЦУ?

 

Дело в том, что это моя первая серьёзная работа, мне интересно Ваше мнение, а то может я вобще зря парюсь и всё не так уж плохо. Как вы считаете для устройства компрессии данных, может удовлетворять такая его реализация, что оно способно обрабатывать 40-30 миллионов символов в секунду при очень высокой степени сжатия. Тестировал при установленных ОЗУ по 4096х20 и 4096х12 - степень сжатия составила 35-40%, если как-раз увеличить объем ОЗУ в 8 или ещё круче в 16 раз, что составит 320 Кб ОЗУ степень сжатия возрастёт примерно до 80-90%! Хотя при этом число тактов затрачиваемых на обработку одного цикла будет расти из-за увеличения коллизий и числа рекурсий внутри конвейера. И всё же как вы считаете, что предпочтительнее максимальная степень сжатия при относительно небольшой скорости (причём универсальное сжатие любых данных, особенно графических, видео, текстовых, менее звуковых, хотя тоже неплохо работает) обработки или же скорость устройства, с быстрым просмотром по ОЗУ и пропуском встретившихся коллизий? Этот очень важно для меня так как я остановился на завершающем этапе и не знаю как мне быть, то ли в корне модифицировать устройство, изменять структуру и т.д., то ли оставлять так как есть (при этом я не имею ввиду фразу "и так сойдёт" :) это не по мне). Вобщем прошу оценить и ответить годится ли моё ЦУ для целенаправленного применения как IP ядро какой-нибудь системы или оно слишком медленно работает и т.д.

 

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

[Rundll 0]

Прошу прощения за флуд...

 

У меня возникли попутно ещё несколько вопросов.

 

To Golikov A.

 

Скажите, а даже если и получится всё в один такт запихнуть, Вы можете примерно оценить, на сколько будет падать частота при увеличении разрядности данных? В данный момент в ЦУ стоит 2 блока ОЗУ (4096х20 и 4096х12) и 20-ти разрядный компаратор. Хотя для достижения максимальной эффективности работы устройства предполагается использовать другую конфигурацию: ОЗУ (65536х24 и 65536х16) между ними 24-х разрядный компаратор. Только что протестировал свою систему (с 4-х ступенчатым конвейером), при таких параметрах частота упала со 157МГц до 145 МГц. Хм.. я считаю, что это норм, интересно какова была бы разность частот в однотактовом ЦУ?

 

Дело в том, что это моя первая серьёзная работа, мне интересно Ваше мнение, а то может я вобще зря парюсь и всё не так уж плохо. Как вы считаете для устройства компрессии данных, может удовлетворять такая его реализация, что оно способно обрабатывать 40-30 миллионов символов в секунду при очень высокой степени сжатия. Тестировал при установленных ОЗУ по 4096х20 и 4096х12 - степень сжатия составила 35-40%, если как-раз увеличить объем ОЗУ в 8 или ещё круче в 16 раз, что составит 320 Кб ОЗУ степень сжатия возрастёт примерно до 80-90%! Хотя при этом число тактов затрачиваемых на обработку одного цикла будет расти из-за увеличения коллизий и числа рекурсий внутри конвейера. И всё же как вы считаете, что предпочтительнее максимальная степень сжатия при относительно небольшой скорости (причём универсальное сжатие любых данных, особенно графических, видео, текстовых, менее звуковых, хотя тоже неплохо работает) обработки или же скорость устройства, с быстрым просмотром по ОЗУ и пропуском встретившихся коллизий? Этот очень важно для меня так как я остановился на завершающем этапе и не знаю как мне быть, то ли в корне модифицировать устройство, изменять структуру и т.д., то ли оставлять так как есть (при этом я не имею ввиду фразу "и так сойдёт" :) это не по мне). Вобщем прошу оценить и ответить годится ли моё ЦУ для целенаправленного применения как IP ядро какой-нибудь системы или оно слишком медленно работает и т.д.

 

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

[Very_hard 0]

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

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

Например, у Вас за первый такт происходит: {чтение первого ОЗУ -> сравнение прочитанного с входными данными -> выработка или невыработка сигнала write enable + остается какое-то время до прихода следующего фронта}. За второй такт у Вас: {затриггеренный сигнал write enable "движется" :) к блокам памяти + остается скорее всего дофига времени} (или еще что-то делается?). За третий такт Вы пишете или не пишете память.

Так вот, мое имхо: если схема у Вас не работает в нормальном конвейерном режиме, то не нужно триггерить компаратор. И ничего страшного в этом нет. Длительность такта при этом увеличится незначительно(если вообще увеличится, ведь Вы прибавляете задержку распространения и установки сигнала write enable зато выкидываете запас времени из первого такта). Вот эта разница и будет характеризовать уменьшение или неуменьшение рабочей частоты, да еще при условии, что для частоты была критичной именно задержка логики 1-го такта... Вроде так...

 

Зы: Мне интересно, Вы указываете полученную частоту, рассчитанную синтезатором или разводчиком или реального девайса? :)

[Rundll 0]

Зы: Мне интересно, Вы указываете полученную частоту, рассчитанную синтезатором или разводчиком или реального девайса?

 

Синтезатором :)

 

Проблема была изящно решена: По восходящемо фронту читаем, сравниваем, по нисходящему пишем (что-то типа DDR)... Тот же самый девас выдал максимальную частоту....180 МГц!!! Что же это получается млин :)

[Very_hard 0]

Синтезатором

:glare: :) имхо, синтезатор - плохой показатель Все равно после разводки результат будет с-а-авсем другой. ;)

[Rundll 0]

Так всё же, что предпочтительнее??? Будет ли правльно работать устройство так как я его описал или нет?

[Golikov 0]

Могу только сказать что когда я заменил 20 битный счетчик на два 10 битных, один изменялся каждый раз когда первый досчитал, то есть это тот же делитель частоты на 2^20, частота схемы повысилась со 102 до 120 МГц, но это для всей схемы в целом, и 120 это уже ограничение другой ее части, так что выигрыш в скорости меньшая битность дает и ощутимый, но какой именно это уже надо проверять...

 

насчет вашего вопроса про скорость. Сейчас после общения со спартаном 3е, мне кажется что скорость 110-150 мегагерц со средней сложностью схемы для них нормальна, но какая микросхема у вас я сейчас не знаю, частоту можно и поднять, взять какой нить вертекс могучий

 

Вопрос баланс скорости/сжатия... тут я вообще теряюсь. Если есть возможность сделать настраиваемую систему и отдать пользователю варьировать либо скоростью либо сжатием, то я думаю это будет лучше чем что-то фиксировать. Причем можно воспользоваться системой типа ЖЕПЕГ2000, которая жмет сразу с минимальным сжатием, но на уровне передачи можно отбрасывать младшие биты, тем самым увеличивать сжатие, но ронять качество, или увеличивать скорость передачи. Подумайте может у вас можно реализовать что то подобное...

 

Насчет хорошести вашей системы:)...

Странно что вам не известно хорошо или плохо работает ваш метод? Вы как разработчик должны были первым найти аналоги, с кем вы конкурируете, и сравнивать характеристики уже с ними. Как же можно разрабатывать в слепую?

 

А вообще в целом сжатие 40% для изображения это мало, в моей работе по сжатию изображения, я сравнивался с жепегом 2000, в среднем метод дает объем данных 14% от несжатого варианта, это при весьма приличном качестве, конечно характеристика субъективна, но на некоторых картинках глазам потери были невидны. А так жепег сжимал до 6%, с достойным уровнем качества. Но от жепега на таком сжатие не кто не требовал скорости 40 мегабайт в секунду, жепег на такое не способен. Но ему и не надо. А надо ли вам? и какая у вас система сжатия с потерями или без? если без то 40% это даже не вериться, опять же скорость внушающая...

 

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

 

ой опять слишком длинно:)

[Golikov 0]

Так всё же, что предпочтительнее??? Будет ли правльно работать устройство так как я его описал или нет?

 

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

 

Опять же, как говорит Very_hard, синтезатор действительно перестраховывается, указывая вам допустимую частоту, может его новое видение схемы позволило где то скомпенсировать перестраховки…

 

 

Кстати вопрос, а может ли схема не работать на частоте указанной синтезатором? В смысле может ли возникнуть такая ситуация, что синтезатор указал не мажерантную оценку частоты, и при нагреве схема перестает работать на данной частоте?

И насколько правдивую оценку частоты можно получить до момента запуска схемы в железе? Где частоту то собственно и не проверишь...

[Rundll 0]

To Golikov A.

 

Моя схема выдаёт хорошие результаты сжатия, ИМХО это максимум от алгоритма LZW, плюс к тому же я описал систему адаптивности кодов, т.е. при разрядности 16, и компрессор и декомпрессор использует сначала 9 битные коды, затем при необходимости наращивает разрядность, это дает отличный результат вместе с результатом степени сжатия данных! Потеря данных абсолютно исключена, вероятность возникновения ошибки минимальна и отслеживается системой. Всё работает, вопрос только в скорости! Как я уже говорил, для меня лишний такт - на кг золота :) Я только не могу понять, почему симулятор мне неправильные результаты выдает, когда я систему описал за один такт! В Modelsim работает превосходно, а вот скажем во встроенном симуляторе MAX PLUS II, после синтеза схема, она работает неправильно или я что-то сделал не так... Я уже и частоту на 10 Мгц ставил всё равно не получается! Вот простой тестовый пример отдельного блока системы, я его описал так (только не ругайтесь, за возм. доп. ошибки, писал на скорую руку, только что):

 

Компонент SRAM DDR:

 

LIBRARY ieee ;

USE ieee.std_logic_1164.all;

USE ieee.std_logic_arith.all;

use IEEE.STD_LOGIC_UNSIGNED.ALL;

 

 

entity SRAM is

generic(

data_width: natural:=8;

adress_width: natural:=12

);

port (

CLK: in std_logic;

data: in std_logic_vector(data_width-1 downto 0);

adress: in std_logic_vector(adress_width-1 downto 0);

we: in std_logic;

dout: out std_logic_vector(data_width-1 downto 0)

);

end SRAM;

 

architecture Memory of SRAM is

 

type memory_block is array ((2**adress_width)-1 downto 0) of std_logic_vector (data_width-1 downto 0);

signal SRAM_TABLE : memory_block:=(others=>(others=>'0')); --for simulation

begin

 

process(CLK) begin

if CLK'event and CLK='1' then

dout<=SRAM_TABLE(conv_integer(adress));

end if;

if CLK'event and CLK='0' then

if we='1' then

SRAM_TABLE(conv_integer(adress))<=data;

end if;

end if;

end process;

 

END memory;

 

Далее собственно сама система с компаратором между двумя ОЗУ:

 

LIBRARY ieee ;

USE ieee.std_logic_1164.all;

USE ieee.std_logic_arith.all;

entity RAM is

generic (CHAR_WIDTH: natural:=8;

CODE_WIDTH: natural:=12

);

port (

CLK: in std_logic;

adress: in std_logic_vector(CODE_WIDTH-1 downto 0);

data_in_1: in std_logic_vector(CHAR_WIDTH+CODE_WIDTH-1 downto 0);

data_in_2: in std_logic_vector(CODE_WIDTH-1 downto 0);

data_out_1: out std_logic_vector(CHAR_WIDTH+CODE_WIDTH-1 downto 0);

data_out_2: out std_logic_vector(CODE_WIDTH-1 downto 0);

we: out std_logic

);

 

end RAM;

 

architecture test of RAM is

component sram

generic(data_width: natural:=20;

adress_width: natural:=12

);

port (

CLK: in std_logic;

data: in std_logic_vector(data_width-1 downto 0);

adress: in std_logic_vector(adress_width-1 downto 0);

we: in std_logic;

dout: out std_logic_vector(data_width-1 downto 0)

);

end component;

 

signal compare_result: std_logic;

signal data_temp: std_logic_vector(CHAR_WIDTH+CODE_WIDTH-1 downto 0);

begin

 

 

M1: SRAM generic map (CHAR_WIDTH+CODE_WIDTH, CODE_WIDTH)

port map (

CLK,

data_in_1,

adress,

compare_result,

data_temp

);

 

compare_result<='1' when data_temp/=data_in_1 else '0';

we<=compare_result;

data_out_1<=data_temp;

 

M2: SRAM generic map (CODE_WIDTH, CODE_WIDTH)

port map (

CLK,

data_in_2,

adress,

compare_result,

data_out_2

);

 

 

end test;

 

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

 

 

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