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

KP580BE51 · Post by **KP580BE51** » 21 Sep 2005 00:56

Dm.uk wrote: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 · Post by **kosmo** » 21 Sep 2005 01:32

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

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

KP580BE51 · Post by **KP580BE51** » 21 Sep 2005 01:40

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

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

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

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

flip_flop · Post by **flip_flop** » 21 Sep 2005 01:52

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

P.S. See "Rate match" and "Elastic buffer"

kosmo · Post by **kosmo** » 21 Sep 2005 02:04

flip_flop wrote:Вот, еще легкое чтиво нашел от любимого нашего Зайлинкса 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 · Post by **KP580BE51** » 21 Sep 2005 02:13

flip_flop wrote:Вот, еще легкое чтиво нашел от любимого нашего Зайлинкса 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 · Post by **flip_flop** » 21 Sep 2005 02:25

kosmo wrote:Кстати, наш любимый Зайлинкс прекрасно обходится без 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 · Post by **flip_flop** » 21 Sep 2005 02:43

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

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

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

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

tengiz · Post by **tengiz** » 21 Sep 2005 02:53

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

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

KP580BE51 · Post by **KP580BE51** » 21 Sep 2005 02:57

flip_flop wrote:
KP580BE51 wrote:Из полезного, ИМХО только как 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 или сдвиговый регистр?

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

flip_flop · Post by **flip_flop** » 21 Sep 2005 03:02

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

То что я уже говорил - отсутствие сосредоточенного в узкой полосе излучения

Correct.

А скрамблер еще больше размазывает сигнал по спектру (eliminates repetitive patterns)- представьте передачу одного и того же байта. И все это может накладываться на SSC in reference clocks для усиления вящего эффекта. EMI noise ... Go noise?

flip_flop · Post by **flip_flop** » 21 Sep 2005 03:09

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

Садитесь - ДВА. В семестре. Для мултигигабитных клоков jitter - это священная корова.

KP580BE51 · Post by **KP580BE51** » 21 Sep 2005 03:09

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

То что я уже говорил - отсутствие сосредоточенного в узкой полосе излучения
Correct. А скрамблер еще больше размазывает сигнал по спектру (eliminates repetitive patterns)- представьте передачу одного и того же байта. И все это может накладываться на SSC in reference clocks для усиления вящего эффекта. EMI noice ... Go noice?

Вы (случайно) не о CDMA?

flip_flop · Post by **flip_flop** » 21 Sep 2005 03:14

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

То что я уже говорил - отсутствие сосредоточенного в узкой полосе излучения
Correct. А скрамблер еще больше размазывает сигнал по спектру (eliminates repetitive patterns)- представьте передачу одного и того же байта. И все это может накладываться на SSC in reference clocks для усиления вящего эффекта. EMI noise ... Go noise?

Вы (случайно) не о CDMA?

Нет - я о скоростных интерфейсах (PCIe, SATA, SAS, 10G Ethernet) - они тоже "свистят".

KP580BE51 · Post by **KP580BE51** » 21 Sep 2005 03:17

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

Садитесь - ДВА. В семестре. Для мултигигабитных клоков jitter - это священная корова.

PLL разводить нужно уметь.

Может как-то определимся, что конкретно обсуждаем? PCI с I2C или гигабитный канал? Может уже и есть FPGA, которые на гигагерцах работают

но я о них не слышал. Есть микросхеммы которые клок восстанавливают. Там свои проблеммы. ИМХО.