Интересно. Но я так и не понял, почему обязательно использовать оба фронта. Ту же сигнальную систему можно и на один фрон накрутить. Кроме очевидного соображения, что тактовая частота вдвое больше максимальной частоты данных, а при использовании обоих фронтов - нет. Ещё, почему-то, я ожидал какой-то магии, типа сложителя, который сам на лету определяет, что бегущий перенос уже "весь закончился" и выдаёт сигнал "результат готов". А оказалось всё банальней - бьём схему на ступени конвейера, задержки ступеней конвейера выставляем руками (на картинке - элемент "DELAY"). Порадовала сигнальная система (R/A), которая даёт удобный способ соединения стадий конвейера. Осталось непроиллюстрированным заявление "в традиционной системе стадия конвейера вынуждена дождаться, пока следующая стадия освобоится, а потом уже передавать в неё данные, таким образом, максимальная скорость прокачивания данных через конвейер падает вдвое, либо нужно строить хитрую логику, которая будет анализировать занятость не только следующей стадии конвейера, а ещё и тех, которые стоят за ней". Нет иллюстрации, как скорость возрастает вдвое против более традиционной схемотехники. Ещё неясно вот что: На картинке с конвейером, который ничего не делает, а просто FIFO, при пустом конвейере есть прямой datapath со входа на выход. То есть, данные на выходе актуальны через короткое время, после попадания их на вход. Тем не менее, на выходе сигнал "данные готовы"(R) вылетает через такое же время, как если бы происходили переключения switches, и "запомненные" данные перекачивались бы с одной ступени FIFO в другую. Нельзя ли тут ещё как-нибудь сэкономить - чтоб задежка выходного R относительно входного R при "прямом" попадании данных была бы меньше. На "шине управления" (R/A) идёт полноценное переключение всех каскадов - поэтому задержка R стандартная. И ещё. На той же картинке, при пустой очереди, мы видим, как данные со входа "прямо" (без переключений) попадают на выход. А параллельно, данные с выхода - на вход (если оторвать первый и последний каскады, то остальная схемотехника симметрична). Интересно, можно ли из этой симметрии извлечь какую-нибудь практическую пользу.
Короче, я ни разу не схемотехник. Потому и мысли такие дилетантские. Статья интересная.
Ещё, почему-то, я ожидал какой-то магии, типа сложителя, который сам на лету определяет, что бегущий перенос уже "весь закончился" и выдаёт сигнал "результат готов". А оказалось всё банальней - бьём схему на ступени конвейера, задержки ступеней конвейера выставляем руками (на картинке - элемент "DELAY"). Порадовала сигнальная система (R/A), которая даёт удобный способ соединения стадий конвейера.
Осталось непроиллюстрированным заявление "в традиционной системе стадия конвейера вынуждена дождаться, пока следующая стадия освобоится, а потом уже передавать в неё данные, таким образом, максимальная скорость прокачивания данных через конвейер падает вдвое, либо нужно строить хитрую логику, которая будет анализировать занятость не только следующей стадии конвейера, а ещё и тех, которые стоят за ней". Нет иллюстрации, как скорость возрастает вдвое против более традиционной схемотехники.
Ещё неясно вот что:
На картинке с конвейером, который ничего не делает, а просто FIFO, при пустом конвейере есть прямой datapath со входа на выход. То есть, данные на выходе актуальны через короткое время, после попадания их на вход. Тем не менее, на выходе сигнал "данные готовы"(R) вылетает через такое же время, как если бы происходили переключения switches, и "запомненные" данные перекачивались бы с одной ступени FIFO в другую. Нельзя ли тут ещё как-нибудь сэкономить - чтоб задежка выходного R относительно входного R при "прямом" попадании данных была бы меньше. На "шине управления" (R/A) идёт полноценное переключение всех каскадов - поэтому задержка R стандартная.
И ещё. На той же картинке, при пустой очереди, мы видим, как данные со входа "прямо" (без переключений) попадают на выход. А параллельно, данные с выхода - на вход (если оторвать первый и последний каскады, то остальная схемотехника симметрична). Интересно, можно ли из этой симметрии извлечь какую-нибудь практическую пользу.
Короче, я ни разу не схемотехник. Потому и мысли такие дилетантские. Статья интересная.
Reply
С моей текущей работой я просто не успеваю прочитать всё интересное, поэтому мои посты - закладки для меня самого.
Reply
Во время первого фронта мы записываем "данные" и распространяем изменения. Во время второго фронта мы записываем "не готово" и распространяем сброс.
Пока получается так.
Я ещё подумаю и почитаю.
Reply
Leave a comment