Вопросы по электронике?

[KP580BE51]

> ИМХО, достаточно чтобы клок пришел позже на время //значительно// позже разброса прихода сигнала про линиям данных.

а ведь мы понятия не имеем когда (в какой момент времени, относительно клока первого домена) "придет" клок второго домена ...

А вот это, самое душераздирающее известие. Честное слово, не знаю. Это нужно очень много думать. Если есть сигнал "готовность данных" то по этому сигналу делатся RS триггер. По записи (WR & Ready) S поднимается, при чтении он опускается. Я делал именно так. Так есть гарантия что он запишется один раз, (я зводил обратно сигнал с него) и что он прочтется один раз. (прочитаться второй раз он не может потому что при первом чтении он сбрасывается)
НО!!! Это я сделал я, там где оно прямо просилось. Может быть оно и не поравильно.

PS: Это допрос или просто флейм?

PPS: У меня ОЧЕНЬ болшой опыт ваяния всего что в голову взбредет на К155, К555, К1533, К176, К561 итд. Но на верилоге только месяца 3.

[Dm.uk]

> А вот это, самое душераздирающее известие. Честное слово, не знаю. Это нужно очень много думать.

...


> PS: Это допрос или просто флейм?

и не то и не другое, ишем т.с. истину


> Если есть сигнал "готовность данных" то по этому сигналу делатся RS триггер. По записи (WR & Ready) S поднимается, при чтении он опускается. Я делал именно так. Так есть гарантия что он запишется один раз, (я зводил обратно сигнал с него) и что он прочтется один раз. (прочитаться второй раз он не может потому что при первом чтении он сбрасывается)

ok, not too bad!, ето почти то самое решение о котором шла речь ... Т.е."посылатель" из домена 1 выставляет REQ/DATA_ready/whatever), а "получатель" из домена 2 после прочтения выставляет ACK/DATA_read/whatever итд. Только, разумеется, и "посылатель" (домен 1) и "получатель" (домен 2) должны проверить был ли предыдуший REQ/ACK "обработан". Реализуется, например, наличием FSM в каждом из доменов. flip_flop на 1-ой странице топика правильно поправил меня указав на наличие/отсутствие "обратной связи"


а теперь : как можно елементарнейше решить задачку 1.б.1 ?


> PPS: У меня ОЧЕНЬ болшой опыт ваяния всего что в голову взбредет на К155, К555, К1533, К176, К561 итд. Но на верилоге только месяца 3.

[Флейм=ON]
ето неважно, HDL ето только т.с. удобный язык изложения того что Вы хотели сказать...
[Флейм=OFF]

[kosmo]

> Не делая никаких допущений о частотах клоков?

разумеется решение "с 2 тиггерами" требует "допушения" Смысл вопроса (точнее подвопроса, назовем его 1.б.1.) в том как "красиво" сделать "трансфер" (с допушениями как в 1.а., но без "громоздскости" которое требуется при решении 1.б.

Короче, я хотел сказать, что если частоты клоков сильно отличаюстся, то серые счетчики не помогут.

[KP580BE51]

> Не делая никаких допущений о частотах клоков?

разумеется решение "с 2 тиггерами" требует "допушения" Смысл вопроса (точнее подвопроса, назовем его 1.б.1.) в том как "красиво" сделать "трансфер" (с допушениями как в 1.а., но без "громоздскости" которое требуется при решении 1.б.

Короче, я хотел сказать, что если частоты клоков сильно отличаюстся, то серые счетчики не помогут.

Без конкретного Т.З. все это - сферический конь в вакууме.

[kosmo]

ok, not too bad!, ето почти то самое решение о котором шла речь ... Т.е."посылатель" из домена 1 выставляет REQ/DATA_ready/whatever), а "получатель" из домена 2 после прочтения выставляет ACK/DATA_read/whatever итд. Только, разумеется, и "посылатель" (домен 1) и "получатель" (домен 2) должны проверить был ли предыдуший REQ/ACK "обработан". Реализуется, например, наличием FSM в каждом из доменов. flip_flop на 1-ой странице топика правильно поправил меня указав на наличие/отсутствие "обратной связи"

Распределенный FSM с возможными невалидными состояниями - ненадежная конструкция.

[flip_flop]

> Не делая никаких допущений о частотах клоков?

разумеется решение "с 2 тиггерами" требует "допушения" Смысл вопроса (точнее подвопроса, назовем его 1.б.1.) в том как "красиво" сделать "трансфер" (с допушениями как в 1.а., но без "громоздскости" которое требуется при решении 1.б.

Короче, я хотел сказать, что если частоты клоков сильно отличаюстся, то серые счетчики не помогут.

Без конкретного Т.З. все это - сферический конь в вакууме.

А давайте сформулируем Вам ТЗ на основе полюбившегося Вам (вполне заслуженно) SATA интерфейса. Дано 7 контактов в элегантном тоненьком кабеле- 3 земли, 2 дифференциальные пары (одна от приемника, вторая от передатчика). Разница в скорости передачи от диска к чипу и наооборот составляет +350 -5000 ppm. Никаких Вам отдельных клоков и статусных сигналов, ну совсем никаких. Ваши действия?

[KP580BE51]

А давайте сформулируем Вам ТЗ на основе полюбившегося Вам (вполне заслуженно) SATA интерфейса. Дано 7 контактов в элегантном тоненьком кабеле- 3 земли, 2 дифференциальные пары (одна от приемника, вторая от передатчика). Разница в скорости передачи от диска к чипу и наооборот составляет +350 -5000 ppm. Никаких Вам отдельных клоков и статусных сигналов, ну совсем никаких. Ваши действия?

Ябы эти статусные биты просто в поток добавил: Нет данных - просто пакет статусный, есть данные - данные (в пакете - статус). К примеру при записи на винт - вниз - данные, вверх (там к томуже полный дуплекс) - статус, есть место, нет места итд. Там кажись так и сделано. Что-то там про CRC я читал, а если есть контроль ошибок, то есть комманды и на перезапрос данных, положительные/отридцательные квитанции приема данных итд.

Только это похоже уже не про согласование клоков.

[flip_flop]

А давайте сформулируем Вам ТЗ на основе полюбившегося Вам (вполне заслуженно) SATA интерфейса. Дано 7 контактов в элегантном тоненьком кабеле- 3 земли, 2 дифференциальные пары (одна от приемника, вторая от передатчика). Разница в скорости передачи от диска к чипу и наооборот составляет +350 -5000 ppm. Никаких Вам отдельных клоков и статусных сигналов, ну совсем никаких. Ваши действия?

Ябы эти статусные биты просто в поток добавил: Нет данных - просто пакет статусный, есть данные - данные (в пакете - статус). К примеру при записи на винт - вниз - данные, вверх (там к томуже полный дуплекс) - статус, есть место, нет места итд. Там кажись так и сделано. Что-то там про CRC я читал, а если есть контроль ошибок, то есть комманды и на перезапрос данных, положительные/отридцательные квитанции приема данных итд.

Только это похоже уже не про согласование клоков.

Вопрос именно про согласованние входных данных рисивера (данные синхронизированы клоками трансмиттера) с его внутренними клоками (клоками рисивера). Эти клоки могут отличаться по частоте на фиксированное смещение +-350 ppm плюс на смещение SSC (0...-5000 ppm), модулированное частотой 30 KHz. Вопрос остается.

[KP580BE51]

Вопрос именно про согласованние входных данных рисивера (данные синхронизированы клоками трансмиттера) с его внутренними клоками (клоками рисивера). Эти клоки могут отличаться по частоте на фиксированное смещение +-350 ppm плюс на смещение SSC (0...-5000 ppm), модулированное частотой 30 KHz. Вопрос остается.

Читал что PLLем как-то делают. Думаю что можно соответсвующий Appnote найти.

http://www.analog.com/UploadedFiles/Dat ... 800_02.pdf
http://www.altera.com/literature/ug/ug_sgx.pdf

Все уже давно придумано.

[flip_flop]

Вопрос именно про согласованние входных данных рисивера (данные синхронизированы клоками трансмиттера) с его внутренними клоками (клоками рисивера). Эти клоки могут отличаться по частоте на фиксированное смещение +-350 ppm плюс на смещение SSC (0...-5000 ppm), модулированное частотой 30 KHz. Вопрос остается.

Читал что PLLем как-то делают. Думаю что можно соответсвующий Appnote найти.

http://www.analog.com/UploadedFiles/Dat ... 800_02.pdf
http://www.altera.com/literature/ug/ug_sgx.pdf

Все уже давно придумано.

Вы в очередной раз не поняли вопрос (или не понимаете что такое PLL/CDR). CDR (на основе PLL или на другой основе) восстанавливает клок трансмиттера на стороне рисивера, но данные, синхронизированные этим клоком траснмиттера надо согласовать с клоком рисивера. Эти клоки (восстановленный клок трансмиттера и клок рисивера) имеет относительно большую разницу по частоте (причем эта разница меняется со временем). Таким образом имеем исходную задачу согласования разных клоковых доменов. Задача давным давно решена, но, как отметил Тенгиз, она достаточно концептуальна. И мы с dm.uk все еще не услышали внятного решения.

[KP580BE51]

Вы в очередной раз не поняли вопрос (или не понимаете что такое PLL/CDR). CDR (на основе PLL или на другой основе) восстанавливает клок трансмиттера на стороне рисивера, но данные, синхронизированные этим клоком траснмиттера надо согласовать с клоком рисивера. Эти клоки (восстановленный клок трансмиттера и клок рисивера) имеет относительно большую разницу по частоте (причем эта разница меняется со временем). Таким образом имеем исходную задачу согласования разных клоковых доменов. Задача давным давно решена, но, как отметил Тенгиз, она достаточно концептуальна. И мы с dm.uk все еще не услышали внятного решения.

Тогда понял. Ябы делал "в лоб" тоесть не согласовывалбы. (мы SATA рассматриваем?) Декодировал пакеты по восстановлиному клоку, считал-бы CRC, и поддерживал-бы протокол, и складывал-бы пакеты в двухпортовое ОЗУ. А уже винчестер (мы про винчестер?) свом процессором уже выгребалбы оттуда пакеты, ставил-бы битики, какие пакеты уже записаны, итд.

[flip_flop]

Ябы делал "в лоб" тоесть не согласовывалбы. (мы SATA рассматриваем?) Декодировал пакеты по восстановлиному клоку,.

Так в том то и дело, что 8b/10b декодер должен работать на своей частоте (стабильной внутренней частоте рисивера, без SSC , частоте работы с паралельными 10b данными, то есть примерно в десять раз ниже частоты встроенного клока входного потока последовательных данных). Задача востанновленного "последовательного" клока (c SSC) - преобразовать последовательные данные на входе рисивера в параллельные, разделить соответственно самого себя (x/10) и доставить параллельные данные вместе с "параллельным" клоком (но отличным от внутреннего "паралельного" клока рисивера) на границу... С другой стороны границы имеем клок рисивера и ждущую шину 10b данных для декодера. Весьма практическая задача (для SATA и других интерфейсов), которая сводится к исходному вопросу о согласовании клоковых доменов - так любимый приветовцами сферический конь в вакууме уже не нужен.

[KP580BE51]

Так в том то и дело, что 8b/10b декодер должен работать на своей частоте (стабильной внутренней частоте рисивера, без SSC , частоте работы с паралельными 10b данными, то есть примерно в десять раз ниже частоты встроенного клока входного потока последовательных данных). Задача востанновленного "последовательного" клока (c SSC) - преобразовать последовательные данные на входе рисивера в параллельные, разделить соответственно самого себя (x/10) и доставить параллельные данные вместе с "параллельным" клоком (но отличным от внутреннего "паралельного" клока рисивера) на границу... С другой стороны границы имеем клок рисивера и ждущую шину 10b данных для декодера. Весьма практическая задача (для SATA и других интерфейсов), которая сводится к исходному вопросу о согласовании клоковых доменов - так любимый приветовцами сферический конь в вакууме уже не нужен.

Хоть я и в упор не могу понять, почему декодер не может работать от восстановленного клока. SSC (Spread Spectrum Clock ?). Для того чтобы успеть все обработать, внутренний клок должен быть по любому быстрее чем восстановленный. ЗАЧЕМ это? Если работает на меньшей частоте и все успевает, зачем ее увеличивать? Если шина ждущая, и 10 битная, то тогда просто - регистр, 10 битный, и сигнал готовности.
Тоест вход -> сдивиговый регистр, счетчик с компаратором на 10, RS триггер. Алгоритм - принимает биты, сдвигаем в сдвиговом регистре, считаем их счетчиком. Как досчитали до 10, то пишем из сдвигововго регистра в выходной триггер, при условии что RS триггер сброшен, и поднимаем этот триггер.
Сигнал из триггера (пропушеный через несколько инверторов) это сигнал READY. По этому сигналу, читаем из выгодного регистра, и сбрасываем RS триггер. Недостатки - внутренняя частота должна быть хотябы процентов на 10 больше чем максимально возможная частота приема.

[flip_flop]

Хоть я и в упор не могу понять, почему декодер не может работать от восстановленного клока. SSC (Spread Spectrum Clock ?). Для того чтобы успеть все обработать, внутренний клок должен быть по любому быстрее чем восстановленный. ЗАЧЕМ это?

Ну договорились в стандарте иметь декодер в Link лейер, а мы рассматриваем PHY. Внутренний клок может быть несколько медленнее востановленного (максимум на 750 ppm). Внутренний клок должен быть синхронным с цифровым "ядром" - один и тот же клок домен. Данные трансмиттера (и его восстановленная копия на рисивере, 10b paralel ) принадлежат к другому клоковому домену. Всего два домена - а Вы в упор не хотите клоки согласовывать А надо ведь... (see pg.1) Передаю эстафету dm.uk - мне спать пора, "караул устал" . BB.

[Dm.uk]

ok, ok,
думаю что "головоломки про клоки" можно разделить на две группы.

1-я, простая.
Внутри IC (любого), частоты 1 и 2 фиксиованы, ответы +/- озвучены. В зависимости от соотношения частот выбирается то или иное решение.
Варианты неплохо расписаны вот тут :
http://www.cadence.com/whitepapers/cdc_wp.pdf

KP580BE51, не торопитесь, прочтите "от корки до корки"

что бы не быть "абстрактным", дубовый пример : у Вас есть FPGA, вы делаете конвертор (с буферизацией и прочими прибамбасами) из одного интерфейса в другой (что бы отойти от 8b/10b, например, PCI -> I2C или что-то в етом роде).


2-я, "динамическая", сформулирована flip-flopом


PS мне надо пару дней подумать, не в ушерб проекту , над тем что сказал kosmo. Согласен про соотношения частот (см. link), но почему дубовый handshake "нестабилен", хммм ...

[KP580BE51]

ok, ok,
думаю что "головоломки про клоки" можно разделить на две группы.

1-я, простая.
Внутри IC (любого), частоты 1 и 2 фиксиованы, ответы +/- озвучены. В зависимости от соотношения частот выбирается то или иное решение.
Варианты неплохо расписаны вот тут :
http://www.cadence.com/whitepapers/cdc_wp.pdf

KP580BE51, не торопитесь, прочтите "от корки до корки"

Прочитал. Кое что применял, кое что - нет.

что бы не быть "абстрактным", дубовый пример : у Вас есть FPGA, вы делаете конвертор (с буферизацией и прочими прибамбасами) из одного интерфейса в другой (что бы отойти от 8b/10b, например, PCI -> I2C или что-то в етом роде).

I2C - 400кгц максимум. PCI - 33мгц минимум. Тоесть I2C вообще проблем нету. Можно как угодно делать.

2-я, "динамическая", сформулирована flip-flopом

Или описана на fig11. ИМХО сигнал с 200мгц нужно стараться обрабатывать до кокого-то логического конца оставаясь в домене 200мгц, а 166 - в домене 166 мгц. И синхронизировать их уже на более высоком уровне "пришел пакет из 166, послали пакет в 200. Все ИМХО.

PS мне надо пару дней подумать, не в ушерб проекту , над тем что сказал kosmo. Согласен про соотношения частот (см. link), но почему дубовый handshake "нестабилен", хммм ...

Распределенный FSM с возможными невалидными состояниями - ненадежная конструкция.

Это? Можно "попасть" на фиг3. И если системма с клоком А будет ждать ответа от сигнала Б, а системма Б. будет ждать запроса, котороый она пропустила по причине небольшого рассогласования клоков (а то и просто, помехи) то все это будет висеть до ресета. Проблемма тайм-аутами решаема. И вообще, ее лучше на уровне софта решать.

У меня ощущение блуждания в 3 соснах.

[kosmo]

И если системма с клоком А будет ждать ответа от сигнала Б, а системма Б. будет ждать запроса, котороый она пропустила по причине небольшого рассогласования клоков (а то и просто, помехи) то все это будет висеть до ресета. Проблемма тайм-аутами решаема. И вообще, ее лучше на уровне софта решать.

Про то, что лучше решать на уровне совта - не согласен, но это неважно, действительно можно решить таймаутами. А как детектировать противоположную ситуацию, когда оба FSMа одновременно шлют друг сругу хендшейки?

[KP580BE51]

И если системма с клоком А будет ждать ответа от сигнала Б, а системма Б. будет ждать запроса, котороый она пропустила по причине небольшого рассогласования клоков (а то и просто, помехи) то все это будет висеть до ресета. Проблемма тайм-аутами решаема. И вообще, ее лучше на уровне софта решать.

Про то, что лучше решать на уровне совта - не согласен,

Это вопрос религиозный.

но это неважно, действительно можно решить таймаутами. А как детектировать противоположную ситуацию, когда оба FSMа одновременно шлют друг сругу хендшейки?

Дык, так часто-ты то разные.... Иж точно не коггерентны... Это не всегда плохо.

[flip_flop]

Вот, еще легкое чтиво нашел от любимого нашего Зайлинкса http://www.engr.sjsu.edu/crabill/module06.pdf (for undergrade students in digital design using Xilinx FPGA). Enjoy! Несмотря на некоторые мелкие огрехи в деталях, основная концепция изложена неплохо. Остается открытым еще один вопрос - зачем использовать и скрамблер и 8b10b енкодер? А вообще пора к аналоговому и RF миру двигать, хотя, как мы видим, и в цифровых трех соснах можно заблудиться
P.S. See "Rate match" and "Elastic buffer"

[kosmo]

Вот, еще легкое чтиво нашел от любимого нашего Зайлинкса http://www.engr.sjsu.edu/crabill/module06.pdf (for undergrade students in digital design using Xilinx FPGA). Enjoy! Несмотря на некоторые мелкие огрехи в деталях, основная концепция изложена неплохо. Остается открытым еще один вопрос - зачем использовать и скрамблер и 8b10b енкодер? А вообще пора к аналоговому и RF миру двигать, хотя, как мы видим, и в цифровых трех соснах можно заблудиться
P.S. See "Rate match" and "Elastic buffer"

Кстати, наш любимый Зайлинкс прекрасно обходится без 8/10 энкодера. Используется 66/64. Функции выполняет те же самые, а user data rate выше.

[KP580BE51]

Вот, еще легкое чтиво нашел от любимого нашего Зайлинкса http://www.engr.sjsu.edu/crabill/module06.pdf (for undergrade students in digital design using Xilinx FPGA). Enjoy! Несмотря на некоторые мелкие огрехи в деталях, основная концепция изложена неплохо.

Из полезного, ИМХО только как FPGA грузить с микропроцессора.

Остается открытым еще один вопрос - зачем использовать и скрамблер и 8b10b енкодер?

Что есть скрасблер, я так окончательно и не понял.
А 8б10б - уже писали - чтобы DC убрать, и по началу байту синхронизацию ловить.

А вообще пора к аналоговому и RF миру двигать, хотя, как мы видим, и в цифровых трех соснах можно заблудиться
P.S. See "Rate match" and "Elastic buffer"

Аналоговый мир заканчивается за АЦП. Остаются только проблеммы с ним связанные (постоянная составляющая таже). А для RF нужно чтобы мозги были соответсвенным образом повернуты. Без этого, будет "все собрано правильно, но ничего не работает".

[flip_flop]

Кстати, наш любимый Зайлинкс прекрасно обходится без 8/10 энкодера. Используется 66/64. Функции выполняет те же самые, а user data rate выше.

Дык от стандартов зависит - что стандарты (PCIe, FC, 802.3ap/ae, SAS, SATA) говорят - то и будет делать. У 64/66 оверхед конечно меньше, но нагрузка на PHY возрастает. А есть еще тьма многоуровневых кодировок линий связи (PAMx, duobinary, PR, не путать с кодировкой данных) со своими достоинствами и недостатками. It always depends...

[flip_flop]

Из полезного, ИМХО только как FPGA грузить с микропроцессора.

Я так понял, что Вас только FPGA и интересуют без всяких там analog high speed, high performance, jitter, noise etc. Ну хотя бы про elastic buffer прочитайте для повышения эрудиции в цифровом дизайне. FPGA - это не только цифра, это еще интерфейсы всякие и их согласование.

А 8б10б - уже писали - чтобы DC убрать, и по началу байту синхронизацию ловить.

Не только - но это связано также с RF - "нужно чтобы мозги были соответсвенным образом повернуты"

[tengiz]

Не только - но это связано также с RF - "нужно чтобы мозги были соответсвенным образом повернуты"

То что я уже говорил - отсутствие сосредоточенного в узкой полосе излучения и хорошая усточивость к мощным узкополосным помехам - вроде ведь как раз RF? Других чисто "радио" причин я что-то больше не вижу...

[KP580BE51]

Из полезного, ИМХО только как FPGA грузить с микропроцессора.

Я так понял, что Вас только FPGA и интересуют без всяких там analog high speed, high performance, jitter, noise etc.

Нет. Просто я предпочитаю, если можно решать проблеммы по отдельности, хоть и учитывать их влияние друг на друга. Ну и хочется избежать проблемм в терминологии.
analog high speed - Это мы о чем? О просто RS422, LVDS или о всяких там кодированиях?
high performance - это по моему сейчас разве что на унитазах не пишут.
jitter и noise нужно рассматривать только в конкретике.

Собственно к клокам это имеет очень опосредованное значение.

Ну хотя бы про elastic buffer прочитайте для повышения эрудиции в цифровом дизайне. FPGA - это не только цифра, это еще интерфейсы всякие и их согласование.

"elastic buffer" Это FIFO или сдвиговый регистр?

А интерфейсы мы еще не обсуждали.