Есть определенное устройство куда подается I2C со внешнего мастера для загрузки setupa в "приемник в данном устройстве. В устройстве есть FPGA в котором помимо всего прочего будет I2C master core, который тоже должен иметь возможность загружать "приемник".
Внешние SDA, SCL подключены к FPGA и коммутируются на выходные (из FPGA) SDA_FPGA, SCL_FPGA.
Идея коммутации в том что когда устройство подключено к внешнему "драйверу", I2C идет от него, проходит через FPGA и выходит на SDA_FPGA, SCL_FPGA которые в свою очередь идут на "приемник".
Когда-же устройство работает в stand-alone режиме - SDA_FPGA, SCL_FPGA драйвятся внутренним I2C master coreом.
Вопрос: как правильно определить SDA_FPGA, SCL_FPGA ? По идее, согласно I2C - они оба - open drain, соотв. должны иметь pull-ups. Но I/O FPGA с которым работаю не имеют open-drain настройки (есть pull-up/down, keep, none).
SDA ессно inout, но как определить пины ?
Какой совет ?
Спасибо.
Полная версия этой страницы: Мультиплексирование I2C шины
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
Цитата(Саша Z @ Nov 28 2008, 12:29) 
Есть определенное устройство куда подается I2C со внешнего мастера для загрузки setupa в "приемник в данном устройстве. В устройстве есть FPGA в котором помимо всего прочего будет I2C master core, который тоже должен иметь возможность загружать "приемник".
Внешние SDA, SCL подключены к FPGA и коммутируются на выходные (из FPGA) SDA_FPGA, SCL_FPGA.
Идея коммутации в том что когда устройство подключено к внешнему "драйверу", I2C идет от него, проходит через FPGA и выходит на SDA_FPGA, SCL_FPGA которые в свою очередь идут на "приемник".
Когда-же устройство работает в stand-alone режиме - SDA_FPGA, SCL_FPGA драйвятся внутренним I2C master coreом.
Вопрос: как правильно определить SDA_FPGA, SCL_FPGA ? По идее, согласно I2C - они оба - open drain, соотв. должны иметь pull-ups. Но I/O FPGA с которым работаю не имеют open-drain настройки (есть pull-up/down, keep, none).
SDA ессно inout, но как определить пины ?
Какой совет ?
Спасибо.
Внешние SDA, SCL подключены к FPGA и коммутируются на выходные (из FPGA) SDA_FPGA, SCL_FPGA.
Идея коммутации в том что когда устройство подключено к внешнему "драйверу", I2C идет от него, проходит через FPGA и выходит на SDA_FPGA, SCL_FPGA которые в свою очередь идут на "приемник".
Когда-же устройство работает в stand-alone режиме - SDA_FPGA, SCL_FPGA драйвятся внутренним I2C master coreом.
Вопрос: как правильно определить SDA_FPGA, SCL_FPGA ? По идее, согласно I2C - они оба - open drain, соотв. должны иметь pull-ups. Но I/O FPGA с которым работаю не имеют open-drain настройки (есть pull-up/down, keep, none).
SDA ессно inout, но как определить пины ?
Какой совет ?
Спасибо.
Такой настройки и не надо, что есть open drain - на выход выдается либо '0' либо третье состояние т.е. 'Z'. Реализуется это через логику и использование разрешение выхода I/O FPGA. Когда выходной сигнал '0' то разрешается выход и выдается '0', а когда '1' выход запрещается.
Цитата(Саша Z @ Nov 28 2008, 11:29)
По идее, согласно I2C - они оба - open drain, соотв. должны иметь pull-ups. Но I/O FPGA с которым работаю не имеют open-drain настройки
Какой совет ?
Какой совет ?
Можно имитировать open drain на буфере с z состоянием. Резисторы внешние.
Да, спасибо, понятно.
Что все еще смущает: линия SDA.
Есть SDA вход в FPGA (от внешнего мастера) и выход из FPGA (назовем его SDA_FPGA) который идет на конечный "приемник".
Т.е. SDA_FPGA коммутируется внутри FPGA - либо "закорачивает" на SDA либо выводит SDA от внутреннего мастера.
Что туго представляю это режим passthrough, т.е. когда работает внешний мастер и SDA_FPGA должен просто проводить наружу входной SDA.
Оба, SDA и SDA_FPGA - inout и иммитируют open-drain. Но как арбитровать их направления согласно протоколу I2C ?
Т.е. когда SDA работает на передачу, тогда будет SDA - вход, SDA_FPGA - выход. Когда-же SDA ожидает приема - они меняются ролями, т.е. SDA становится выходом, SDA_FPGA - входом.
Это вроде означает что в HDL коде нужно мониторить протокол и переключать их направления синхронно ? Т.е. получается нечто типа ретранслятора I2C ?
Что все еще смущает: линия SDA.
Есть SDA вход в FPGA (от внешнего мастера) и выход из FPGA (назовем его SDA_FPGA) который идет на конечный "приемник".
Т.е. SDA_FPGA коммутируется внутри FPGA - либо "закорачивает" на SDA либо выводит SDA от внутреннего мастера.
Что туго представляю это режим passthrough, т.е. когда работает внешний мастер и SDA_FPGA должен просто проводить наружу входной SDA.
Оба, SDA и SDA_FPGA - inout и иммитируют open-drain. Но как арбитровать их направления согласно протоколу I2C ?
Т.е. когда SDA работает на передачу, тогда будет SDA - вход, SDA_FPGA - выход. Когда-же SDA ожидает приема - они меняются ролями, т.е. SDA становится выходом, SDA_FPGA - входом.
Это вроде означает что в HDL коде нужно мониторить протокол и переключать их направления синхронно ? Т.е. получается нечто типа ретранслятора I2C ?
Цитата(Саша Z @ Nov 28 2008, 11:29)
Есть определенное устройство куда подается I2C со внешнего мастера для загрузки setupa в "приемник в данном устройстве. В устройстве есть FPGA в котором помимо всего прочего будет I2C master core, который тоже должен иметь возможность загружать "приемник".
Внешние SDA, SCL подключены к FPGA и коммутируются на выходные (из FPGA) SDA_FPGA, SCL_FPGA.
Идея коммутации в том что когда устройство подключено к внешнему "драйверу", I2C идет от него, проходит через FPGA и выходит на SDA_FPGA, SCL_FPGA которые в свою очередь идут на "приемник".
Когда-же устройство работает в stand-alone режиме - SDA_FPGA, SCL_FPGA драйвятся внутренним I2C master coreом.
Вопрос: как правильно определить SDA_FPGA, SCL_FPGA ? По идее, согласно I2C - они оба - open drain, соотв. должны иметь pull-ups. Но I/O FPGA с которым работаю не имеют open-drain настройки (есть pull-up/down, keep, none).
SDA ессно inout, но как определить пины ?
Какой совет ?
Спасибо.
Внешние SDA, SCL подключены к FPGA и коммутируются на выходные (из FPGA) SDA_FPGA, SCL_FPGA.
Идея коммутации в том что когда устройство подключено к внешнему "драйверу", I2C идет от него, проходит через FPGA и выходит на SDA_FPGA, SCL_FPGA которые в свою очередь идут на "приемник".
Когда-же устройство работает в stand-alone режиме - SDA_FPGA, SCL_FPGA драйвятся внутренним I2C master coreом.
Вопрос: как правильно определить SDA_FPGA, SCL_FPGA ? По идее, согласно I2C - они оба - open drain, соотв. должны иметь pull-ups. Но I/O FPGA с которым работаю не имеют open-drain настройки (есть pull-up/down, keep, none).
SDA ессно inout, но как определить пины ?
Какой совет ?
Спасибо.
Для начала.
Протянуть I2C шину через плисину насквозь у вас не получится. Она защелкнется.
Посмотрите на микруху PCA9515. Она предназначена для усиления сигналов шины. В ней предприняты специальные меры, чтобы она не защелкивалась.
Поэтому, коммутировать шину, нужно воспользоваться внешним мультиплексором. Мы, например, использовали SN74CBTLV3257D.
Цитата(Саша Z @ Nov 29 2008, 17:56)
Это вроде означает что в HDL коде нужно мониторить протокол и переключать их направления синхронно ? Т.е. получается нечто типа ретранслятора I2C ?
Выходит что так. Но и тут наверное косяки могут быть....
Цитата(Саша Z @ Nov 29 2008, 17:56)
Это вроде означает что в HDL коде нужно мониторить протокол и переключать их направления синхронно ? Т.е. получается нечто типа ретранслятора I2C ?
Я не въехал. Начните с простого. Реализации двунаправленной шины. Это буфер по Z состоянию и пин bidir. Причем тут синxронизация по переключению. Буфером комбинаторной логикой управляют (по чтению). А если это двунаправленная шина с открытым коллектором, состояние 0 и Z, подтянутое внешним резистором. Ноль всех перетянет.
Оперируйте кучей шинников с открытым коллектором. Ве должно получиться.
Посмотрите реализацию такого буфера. sn74abte16246
Цитата(sazh @ Nov 29 2008, 19:00)
Я не въехал. Начните с простого. Реализации двунаправленной шины. Это буфер по Z состоянию и пин bidir. Причем тут синxронизация по переключению. Буфером комбинаторной логикой управляют (по чтению). А если это двунаправленная шина с открытым коллектором, состояние 0 и Z, подтянутое внешним резистором. Ноль всех перетянет.
Оперируйте кучей шинников с открытым коллектором. Ве должно получиться.
Посмотрите реализацию такого буфера. sn74abte16246
Оперируйте кучей шинников с открытым коллектором. Ве должно получиться.
Посмотрите реализацию такого буфера. sn74abte16246
Незя вроде в лоб сделать транзитом через FPGA двунаправленную шину... Всегда нужно знать в каком направлении идет передача.
Цитата(Sergei_Ilchenko @ Nov 29 2008, 20:05)
Незя вроде в лоб сделать транзитом через FPGA двунаправленную щину... Всегда нужно знать в каком направлении идет передача.
Да, именно об этом и речь
Цитата(Sergei_Ilchenko @ Nov 29 2008, 19:05)
Незя вроде в лоб сделать транзитом через FPGA двунаправленную шину... Всегда нужно знать в каком направлении идет передача.
Вот съимитировал буфер abte16246. inout - имитация открытого стока. Пока не анализировал.
Но направления передачи тут явно нет. Входы выходы тут конечно не open_dr.
Но и незачем. Объединять по двунаправленной шине. (Чем не транзит). Передавать туда обратно по входам выходам.
В любом случае предложены были переключатели да мультиплексоры.
Код
module open_dr_bidir
#(
parameter width = 1
)
(
input oe_n,
inout [width-1:0] data_a,
input [width-1:0] data_bi,
output [width-1:0] data_bo
);
genvar i;
generate for (i = 0; i < width; i = i + 1)
begin : block
assign data_bo[i] = (oe_n == 1'b0) ? data_a[i] : 1'bz,
data_a[i] = ((data_bi[i] == 1'b0) && (oe_n == 1'b0)) ? 1'b0 : 1'bz;
end
endgenerate
endmodule
#(
parameter width = 1
)
(
input oe_n,
inout [width-1:0] data_a,
input [width-1:0] data_bi,
output [width-1:0] data_bo
);
genvar i;
generate for (i = 0; i < width; i = i + 1)
begin : block
assign data_bo[i] = (oe_n == 1'b0) ? data_a[i] : 1'bz,
data_a[i] = ((data_bi[i] == 1'b0) && (oe_n == 1'b0)) ? 1'b0 : 1'bz;
end
endgenerate
endmodule
Цитата(sazh @ Nov 29 2008, 21:55)
Вот съимитировал буфер abte16246. inout - имитация открытого стока. Пока не анализировал.
Но направления передачи тут явно нет. Входы выходы тут конечно не open_dr.
Но и незачем. Объединять по двунаправленной шине. (Чем не транзит). Передавать туда обратно по входам выходам.
В любом случае предложены были переключатели да мультиплексоры.
Но направления передачи тут явно нет. Входы выходы тут конечно не open_dr.
Но и незачем. Объединять по двунаправленной шине. (Чем не транзит). Передавать туда обратно по входам выходам.
В любом случае предложены были переключатели да мультиплексоры.
Код
module open_dr_bidir
#(
parameter width = 1
)
(
input oe_n,
inout [width-1:0] data_a,
input [width-1:0] data_bi,
output [width-1:0] data_bo
);
genvar i;
generate for (i = 0; i < width; i = i + 1)
begin : block
assign data_bo[i] = (oe_n == 1'b0) ? data_a[i] : 1'bz,
data_a[i] = ((data_bi[i] == 1'b0) && (oe_n == 1'b0)) ? 1'b0 : 1'bz;
end
endgenerate
endmodule
#(
parameter width = 1
)
(
input oe_n,
inout [width-1:0] data_a,
input [width-1:0] data_bi,
output [width-1:0] data_bo
);
genvar i;
generate for (i = 0; i < width; i = i + 1)
begin : block
assign data_bo[i] = (oe_n == 1'b0) ? data_a[i] : 1'bz,
data_a[i] = ((data_bi[i] == 1'b0) && (oe_n == 1'b0)) ? 1'b0 : 1'bz;
end
endgenerate
endmodule
Сорри, я сижу на VHDLe, очень мало знаком с Верилогом.
Можно то что вы хотели сказать выразить VHDLем ?
Цитата(sazh @ Nov 29 2008, 20:55)
Вот съимитировал буфер abte16246. inout - имитация открытого стока. Пока не анализировал.
Но направления передачи тут явно нет.
Да ну, а вывод oe_n - это что?Но направления передачи тут явно нет.
Топикстартеру - а если просто запараллелить обе I2C шины? I2C поддерживает multimaster.
Цитата(XVR @ Dec 1 2008, 14:46)
Да ну, а вывод oe_n - это что?
А ничего. Можете убрать.
Цитата(Саша Z @ Nov 30 2008, 21:49)
Сорри, я сижу на VHDLe, очень мало знаком с Верилогом.
Можно то что вы хотели сказать выразить VHDLем ?
Можно то что вы хотели сказать выразить VHDLем ?
Сорри, на VHDL не могу. На типизации загнусь. У Вас же есть rtl просмотрщик. Да и в тексте все просто.
А на последок я скажу. Если в fpga есть модуль, который может быть то мастером, то подчиненным, и все управление на нем, по идее внешних буферов не надо.
Хотя как это моделировать - черт его знает.
Код
module open_dr_scl
(
inout scl_i2c,
input clk_fpga,
input stop_clk_fpga,
input [3:0] data_in,
output reg [3:0] data_out
);
reg [3:0] ct;
always @(posedge clk_fpga)
begin
if (stop_clk_fpga) ct <= 4'hf;
else ct <= ct + 1'b1;
end
assign scl_i2c = (ct[3] == 1'b0) ? 1'b0 : 1'bz;
always @(posedge scl_i2c)
begin
data_out <= data_in;
end
endmodule
(
inout scl_i2c,
input clk_fpga,
input stop_clk_fpga,
input [3:0] data_in,
output reg [3:0] data_out
);
reg [3:0] ct;
always @(posedge clk_fpga)
begin
if (stop_clk_fpga) ct <= 4'hf;
else ct <= ct + 1'b1;
end
assign scl_i2c = (ct[3] == 1'b0) ? 1'b0 : 1'bz;
always @(posedge scl_i2c)
begin
data_out <= data_in;
end
endmodule
Цитата(sazh @ Dec 1 2008, 16:00)
А ничего. Можете убрать.
Тогда не будет работать. Посмотрите на I2C трансляторы, у них внутри вообще аналоговые схемы 
Цитата(XVR @ Dec 1 2008, 14:46)
Топикстартеру - а если просто запараллелить обе I2C шины? I2C поддерживает multimaster.
Отвечу за топикстартера.
Самопальный мастер, который часто приходится реализовывать на FPGA или микроконтроллере для одномастерной шины реализуется очень просто. Можно сказать - халявно. А вот многомастерный - это уже арбитраж вводить нужно.
Цитата(Михаил_K @ Dec 2 2008, 15:38)
Отвечу за топикстартера.
Самопальный мастер, который часто приходится реализовывать на FPGA или микроконтроллере для одномастерной шины реализуется очень просто. Можно сказать - халявно. А вот многомастерный - это уже арбитраж вводить нужно.
У него уже есть арбитраж (вообще вне МК), т.к. он собрался коммутировать I2C шину от 2х мастеров через FPGA. Если моменты неактивности мастера в МК известны, и мастер в FPGA будет использовать только их, то на I2C шину можно прямо повесить оба мастера в параллель (Если только у МК нету параллельно включенного слейва, но это уже извращение Самопальный мастер, который часто приходится реализовывать на FPGA или микроконтроллере для одномастерной шины реализуется очень просто. Можно сказать - халявно. А вот многомастерный - это уже арбитраж вводить нужно.
)
Цитата(XVR @ Dec 2 2008, 18:37)
У него уже есть арбитраж (вообще вне МК), т.к. он собрался коммутировать I2C шину от 2х мастеров через FPGA. Если моменты неактивности мастера в МК известны, и мастер в FPGA будет использовать только их, то на I2C шину можно прямо повесить оба мастера в параллель (Если только у МК нету параллельно включенного слейва, но это уже извращение )
)Возможно я не совсем точно задал вопрос, но дилемма была как раз не о multi-masterности (ибо оба мастера могут работать заведомо только раздельно, т.е. в разделчные промежутки времени что всегда заранее известно - этот факт был правилчьноподмечен в ветке).
Дилемма была в ситуации когда работает внешний мастер (коммутация - в FPGA). Проблема возникает в линии SDA когда должен быть "переворот" направлений (например acknowledge после передачи адреса/данных). Понятно что в коде оба SDA - вход и SDA - выход определены как tri-state, но "переворот" направления не может быть "автоматическим",т.е. кто-то в коде должен отслеживать traffic и управлять направлениями сквозной SDA линии...
Цитата(Саша Z @ Dec 2 2008, 23:39)
Возможно я не совсем точно задал вопрос, но дилемма была как раз не о multi-masterности (ибо оба мастера могут работать заведомо только раздельно, т.е. в разделчные промежутки времени что всегда заранее известно - этот факт был правилчьноподмечен в ветке).
Дилемма была в ситуации когда работает внешний мастер (коммутация - в FPGA). Проблема возникает в линии SDA когда должен быть "переворот" направлений (например acknowledge после передачи адреса/данных). Понятно что в коде оба SDA - вход и SDA - выход определены как tri-state, но "переворот" направления не может быть "автоматическим",т.е. кто-то в коде должен отслеживать traffic и управлять направлениями сквозной SDA линии...
Не надо ничего никуда переворачивать. И I2C сквозь FPGA пропускать не надо. Нужно сделать в FPGA банальный I2C мастер и его ноги SDA и SCL включить параллельно мастеру в МК и приемнику.
Дилемма была в ситуации когда работает внешний мастер (коммутация - в FPGA). Проблема возникает в линии SDA когда должен быть "переворот" направлений (например acknowledge после передачи адреса/данных). Понятно что в коде оба SDA - вход и SDA - выход определены как tri-state, но "переворот" направления не может быть "автоматическим",т.е. кто-то в коде должен отслеживать traffic и управлять направлениями сквозной SDA линии...
Цитата(Саша Z @ Dec 2 2008, 23:39)
Дилемма была в ситуации когда работает внешний мастер (коммутация - в FPGA). Проблема возникает в линии SDA когда должен быть "переворот" направлений (например acknowledge после передачи адреса/данных). Понятно что в коде оба SDA - вход и SDA - выход определены как tri-state, но "переворот" направления не может быть "автоматическим",т.е. кто-то в коде должен отслеживать traffic и управлять направлениями сквозной SDA линии...
На заметку
Линия SCK тоже двунаправленная...
Цитата(XVR @ Dec 3 2008, 00:34)
Не надо ничего никуда переворачивать. И I2C сквозь FPGA пропускать не надо. Нужно сделать в FPGA банальный I2C мастер и его ноги SDA и SCL включить параллельно мастеру в МК и приемнику.
+1
Цитата(XVR @ Dec 3 2008, 01:34)
Не надо ничего никуда переворачивать. И I2C сквозь FPGA пропускать не надо. Нужно сделать в FPGA банальный I2C мастер и его ноги SDA и SCL включить параллельно мастеру в МК и приемнику.
Да, точно, ежели стандард поддерживает multi-masterность - действительно должно быть просто...
Одно понять - pull-upы. Внешняя система в принципе автономна, у нее есть свои I2C "приемники", т.е. свои pull-ups. Когда-же я к ней подключаю свой "аппаратус" то у него стоят свои pull-ups (ибо он может и в stand-alone работать).
Получается при подключении моего устройства к системе, будут по 2 pull-upа запараллелены. Это может и не проблема если pull-upы могут быть в range (например от 1к до 10к). Но ежели нужен более точная их величина - тогда по идее может понадобится их коммутация. Хотя и это решаемо (FETный ключ как функция от сигнала режима работы).
Какое у Вас Vcc?
Скорость обмена у Вас какая?
Какие длины линий?
Скорость обмена у Вас какая?
Какие длины линий?
Цитата(Sergei_Ilchenko @ Dec 3 2008, 16:34)
Какое у Вас Vcc?
Скорость обмена у Вас какая?
Какие длины линий?
Скорость обмена у Вас какая?
Какие длины линий?
В самой системе линии короткие, но когда подключается мое устройство - длины будут примерно 15-20 см.
Скорости - не думаю что будет более чем стандартные 400кHz, Vcc = 3.3V
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.