vitus_strom

а как насчет завести в классе переменную и при каждом вызове конструктора инкрементировать ее, если надо при каждом вызове деструктора декрементировать?

И мне тоже если можно на motspan@mail.ru

вообще-то счетчик есть аккумулятор только когда на одном из входов у него 1 а описать это так process© begin if (C'event and C='1') then Length<= length+'1' end if; end process; только не уверен что пройдет Length поскольку это атрбут в вхдл

еще в процессе FOR .... LOOP но это то же самое практически, проще по моему нет

Если речь действительно о Виртексе то у него нет асинхронной предустановки триггеров (примитивных) только асинхронный сброс, поэтому исходить нужно из этого если действительно нужен пресет поставте инвертор на входе и инвертор на выходе триггера с асинхронным сбросом

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

www.occ.com www.jobs.cz - по чехии

посмотри на www.qualcomm.com

откоментировать строки library UNISIM; use UNISIM.VComponents.all; там же красным по зеленому написано а трансляцию выключать совсем не обязательно

Если у шин разные названия то их вместе напрямую не соединишь, нужно создать компонент, внутри которого буффера входы на одну шину выходы на другую и потом правильно поименовать

ага и оба должны работать в линейном режиме

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

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

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

Тогда сложнее очень бы посоветовал почитать даташит например вот что написано на длл для виртекс-е: "Input Clock Changes Changing the period of the input clock beyond the maximum drift amount requires a manual reset of the CLKDLL. Failure to reset the DLL produces an unreliable lock signal and output clock. It is possible to stop the input clock with little impact to the DLL. Stopping the clock should be limited to less than 100 µs to keep device cooling to a minimum. The clock should be stopped during a Low phase, and when restored the full High period should be seen. During this time, LOCKED stays High and remains High when the clock is restored. When the clock is stopped, one to four more clocks are still observed as the delay line is flushed. When the clock is restarted, the output clocks are not observed for one to four clocks as the delay line is filled. The most common case is two or three clocks. In a similar manner, a phase shift of the input clock is also possible. The phase shift propagates to the output one to four clocks after the original shift, with no disruption to the CLKDLL control."

отлаживать какой то отдельный кусочек в FPGA ИМХО нет никакого смысла потому как даже задав размещение раутер моежет разводить его каждый раз по разному, конечно можно поизвращатьсть с так называемыми хард макросами, но есть ли смысл вот в чем вопрос, по моему мнению если не нужно из FPGA выжимать край, то можно воспользоваться временными ограничениями

Как запрограммируете так и поведет... Будет активный клок сработает, не будет не сработает

Я так думаю передача констрейнтов идет не RLOC'ами а LOC'ми в файл с физическими ограничениями т.е. в PCF-файл