[makc 207]

Никогда не работал с PicoBlaze, но судя по Static Timing Report's, здесь явно не хватает регистра по выходу этой блочной памяти, все проблемы решатся с большим запасом!

 

Это добавит лишний такт. :(

[ClockworkOrange 0]

>>> Никогда не работал с PicoBlaze, но судя по Static Timing Report's, здесь явно не хватает

>>> регистра по выходу этой блочной памяти, все проблемы решатся с большим запасом!

 

>> Это добавит лишний такт.

 

ага. он итак инструкции за два такта выполняет(( а это вообще убить производиттельность на корню..

хотя можно, конечно, и конвеер сделать - но это, во-первых, требует перекраивания модуля выборки и обработки инструкций (+ неизбежное увеличение выполнения инструкций перехода)

во-вторых, это выливается уже совсем другое число SLICE & FF ((

[rloc 49]

>>> Никогда не работал с PicoBlaze, но судя по Static Timing Report's, здесь явно не хватает

>>> регистра по выходу этой блочной памяти, все проблемы решатся с большим запасом!

 

>> Это добавит лишний такт.

 

ага. он итак инструкции за два такта выполняет(( а это вообще убить производиттельность на корню..

хотя можно, конечно, и конвеер сделать - но это, во-первых, требует перекраивания модуля выборки и обработки инструкций (+ неизбежное увеличение выполнения инструкций перехода)

во-вторых, это выливается уже совсем другое число SLICE & FF ((

 

Тогда попробуйте пространственно подвигать память относительно ядра, не всегда P&R это выполняет хорошо. Посмотрите в FPGA редакторе на реальные длины c выхода памяти. Хотя конечно выигрыш будет максимум в 0.1-0.2 нс :(.

Могу лишь успокоить тем, что реально всегда есть запас минимум 20-30%

[ClockworkOrange 0]

>> Тогда попробуйте пространственно подвигать память относительно ядра, не всегда P&R это выполняет хорошо.

 

как ее подвигаешь-то.. блочную память..

сильно сомневаюсь в неоптимальности P&R при заполнении кристалла на 2%

 

 

>> Могу лишь успокоить тем, что реально всегда есть запас минимум 20-30%

 

вот-вот!! собственно тема-то и создавалась из-за того, чтобы найти способ реально этот запас "пощупать".

Изменено 23 мая, 2007 пользователем ClockworkOrange

[rloc 49]

>> Могу лишь успокоить тем, что реально всегда есть запас минимум 20-30%

 

вот-вот!! собственно тема-то и создавалась из-за того, чтобы найти способ реально этот запас "пощупать".

 

Ну как сами понимаете щупать можно только в железе. Мне можете верить на слово, опыт достаточный, начиная еще с Xilinx под DOS и уже не помню с каких кристалов. Скоро подготовлю материал для новой темы, добавлю оптимизма и уверенности разработчикам на ПЛИС, чтоб отпали всякие сомнения в запасе по быстродействию.

[3.14 0]

Так, для общей информации, сейчас гоняю ради спортивного интереса MicroBlaze на 100 МГц (Spartan3E-250) с ошибкой PAR-а аж на 3.5 нс (т.е. период вместо 10 получается 13,5нс) :)

[makc 207]

Так, для общей информации, сейчас гоняю ради спортивного интереса MicroBlaze на 100 МГц (Spartan3E-250) с ошибкой PAR-а аж на 3.5 нс (т.е. период вместо 10 получается 13,5нс) :)

 

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

[3.14 0]

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

Хотя, вот "аптечная точность" при анализе времянок (до 0,1 нс) не вызывает особого доверия, если учесть что даже на сервиспаках обновляются времянки чипов.