tocha

Легко. Как выше сказали, по всей диаграмме на двунаправленный пин подать сигнал z-уровня, а поверх него в соответствующих местах, где ое в нужном положении (буфер развёрнут на вход), подавать нужное значение.

Зачем так всё усложнять. Если надо включить по или N выходов, то можна так сделать: process(s_full) variable v_1 : std_logic := '0'; begin v_1 := '0'; for i in 0 to N-1 loop v_1 := v_1 or d(i); end loop; s_out_or_w <= v_1; end process;

В цепочку включить можно где так ... type bus_arr is array (N downto 0) of std_logic_vector(Size-1 downto 0); signal s_dq :bus_arr := ( others => (others => '0') ); .... begin ... s_dq(0) <= d; q <= s_dq(N); FIFO: for i in 0 to N-1 generate 89. Registers: Reg 90. Port map( 91. CLK_Reg => CLK, 92. D_Reg => s_dq(i), 94. Q_reg => s_dq(i+1), 95. ... 99. CE_Reg => CE 100. ); 101. end generate FIFO; Остальные сигналы по аналогии. Тока непонятно как это всё работать будет :)

Если синтезировать хотите, то да. Использовать желательно только для частоты.

Функция rising_edge(clk) - только одна на процесс. В результате синтезируется в D-триггер с clk на входе синхронизации. А такой вход - только один. Остальные сигналы - по уровню. В принципе ключ - это a <= b and clk. Если глитчи не страшны. А если да - то лучше иметь частоту, выше чем ту, которую надо пропустить и ей тактировать триггера. З.Ы. В доках на синтезатор наверняка написано как синтезировать d-триггер и счётчик. Лучше прочитать. Будет понятней. :)

Сколько процессов - это по желанию. Но все синхронные процессы должны тактироваться одним клоком, если есть возможность. Это правильный подход. Й естественно каждый сигнал должен драйвиться из одного процесса (как уже сказали). Где-то так: count_hs_process:process (rst, clk) begin if rst = '0' then y <= (others => '0'); count_y <= (others => '0'); elsif clk'event and clk = '1' then case state_y is when start => count_y <= (others => '0'); when count => if hs = '1' then count_y <= count_y + '1'; end if; when write => y <= count_y; end case; end if; end process count_hs_process; А из остальных процессов count_y и y - убрать нафиг.

Лучше не забивать. Вряд ли библиотека шалит. Начальное присваивание count_y сделать через ресет и будет лучше. Предупреждения скрыть - конечно хорошо. Но вряд ли поможет. :) П.С. Автору темы. 1.Лучше тактировать одним clk все синхронные процессы, а синхро импульсы развёртки - на вход En тригеров. 2.y <= count_y даст защёлку, может лучше перенести в третий синхронный процесс.

Может Атмеловский ID не нравится. EPCS4 и M25P40 делает одна контора STMicroelectronics, и ID у них одинаковые - 12h

M25P40 - замена Здесь написано как через JTAG прошить EPCS4 http://www.altera.com/literature/an/an370.pdf

Без сомнения сделать можно. ETH-V35 -есть, как делать, обсуждалось. V35-ETH - лично не встречал, но видел E1-ETH, а значит по аналогии можно сделать и V35-ETH. Как корявый путь: 1) Комп1-> конвертор1(Ethernet -> V35) 2) Шифрование 2а) Конвертор (V35 -> E1 ->) 3) Конвертор2 (E1 -> Ethernet ->) 4) Передача по ЛВС (на самом деле тут почти WAN) 5) Конвертор3 (Ethernet -> Е1) 5а) Конвертор (E1 -> V35) 6) Расшифровка 7) Конвертор4 (V35->Ethernet)-> Комп2. Все три конвертора(E1 -> Ethernet, V35 -> E1, Ethernet -> V35 ) существуют.

выделяет фронт сигнала write_to_fifo1

Если в Киеве, могу на диске отдать

http://biakom.com/index.php?cPath=18_3814_...8581ef11449df10 http://fpga-faq.narod.ru/#Использование AT17xxxA для Altera? http://www.altera.com/literature/hb/cyc/cyc_c51013.pdf

http://electronix.ru/forum/index.php?showtopic=9279&hl= p.s. После устаноки сервиспака, sys_cpt.dll надо снова обновлять и ещё: чтоб зря не тратить 60 мин. времени, можно использовать Edit-Replace в любом текстовом редакторе :)

В таймслоте один за одним передаются пакеты (m бит): заголовок, биты С1 (n бит), 1 бит для выравнивания скорости, 1 бит признака наличия бита выравнивания (можно 3 штуки и принимать решение мажоритарно). На входе С1: Пишем в FIFO из С1. По уровню FIFO на входе принимаем решение: передавать или нет дополнительный бит. Скорость передачи С1 в канале 64 кбит/с - ( n/m )*64 кбит/с или ( (n+1)/m )*64 кбит/с На входе в FIFO пишем с v=9600 кбит/с - читаем с V=(n/m)*64 (< 9600), если указатель FIFO идёт вверх - читаем с V=( (n+1)/m )*64 (> 9600), если вниз- читаем с V=( (n)/m )*64 (< 9600). На выходе С1: Пишем в FIFO из ТДМ. Читаем из FIFO и запуливаем в стык С1. Скорость вычитывания из FIFO регулируем джиттером. Если указатель FIFO идёт вверх - увеличиваем скорость вычитки 9600 + x ppm, если вниз- уменьшаем скорость вычитки 9600 - x ppm. П.С. Размер подстройки должен перекрыть возможные отклонения частот и скорости С1 от номиналов.

Делал так. На приёмной и передающей стороне ставится Fifo для выравнивания скоростей и передаваётся информацию о скорости на удалённую сторону. Там восстанавливается скорость и в С1. Р.С. ГБшники приносили свою аппаратуру со стыком С1 - всё работало. Очень удивились. :)

Завести на него сигнал сброса

Скорее всего он хочет вместо конструкции типа process(a, B) begin if a= e1 then data <= b; end if; end process; видеть конструкцию типа process(a, b ,c) begin if a= e1 then data <= b; else data <= c; end if; end process; и тогда ему не придётся синтезировать нежелательные защёлки (они же combinational loops).

HOSTID=DISK_SERIAL_NUM=xxxxxxx, xxxxxxx - hdd number

Ув. коллеги, всё это более или менее понятно. Правда здесь режим IDLE - это не неприятности, а просто пауза когда нет пакетов. Вопрос в следующем: можна ли рассчитывать, что передатчик будет вставлять в этой паузе кол-во единиц кратное 8 или нет?

По правильному DPLL приемника должен работать побитно и ему все равно. <{POST_SNAPBACK}> Я неточно выразился. Мост обрамляет HDLC-маркерами Ethernet пакеты, формирует и выдаёт наружу HDLC-поток, где паузу между кадрами он сам заполняет или HDLC-маркерами или потоком единиц (выбирается битом во внутреннем регистре микросхемы) . Так вот можно ли надеяться, что количество единиц в паузе кратно 8? Или он может вставить и 1 и 2 , и 9, ...

Может кто знает. Есть микросхеа Gigalink GLB100HB, представляющая собой мост Ethernet-HDLC. Пауза между HDLC-кадрами заполняется или маркерами 7Eh или потоком единиц. Вопрос следующий: может количество единиц быть некратным 8 ?

1. Нужно формировть rdclk постоянно и оперировать лишь rdreq? Но ведь внешний процессор не знает скорости поступления данных! Разве что формировать rdclk из wrclk? 2. Я конечно еще поэкспериментирую и, возможно, эта проблема отпадет при замене эпизодической генерации rdclk постоянной генерацией, но ведь сигнал rdempty сбрасывается в ноль с задеркой в несколько тактов rdclk после появления wrfull, значение rdusedw тоже отстает от wrusedw. И, как указывал уважаемый Jenik, пока rdempty = '1' читать не полагается. 3. Большой глубины буфера не требуется, поэтому реально обойтись dff <{POST_SNAPBACK}> А проблема то в чём ?

1. Частоту лучше держать постоянно. 2. Используя выход usedw можно контроллировать количество слов в фифо и в любой момоент иницировать или прекращать запись или чтение. 3. Реализация такого фифо в CPLD будет весьма проблематична по причине отсутствия там (в CPLD) встроенной ОЗУ.

http://forum.electronix.ru/index.php?showt...s_cpt\.dll