Connecting multiple I2C channels simultaneously

Your subject line, "Connecting multiple I2C channels simultaneously" surely achievable - but appears not what you seek.  Suspect "communicating via multiple I2C channels simultaneously" was the real intent...

While not quite, "crystal clear" - sense that you seek to have single I2C function - route via 4 MCU I2C modules - to 4 I2C Slave destinations.  But how do you propose to order each of your 4 MCU I2C peripherals to execute any function - simultaneously?  Does not the code execute sequentially?  And - does Stellarisware/rebrandware support multiple peripheral access - simultaneously?  Might not this answer be key to your quest?

DMA comes to mind - but while somewhat automating the process - doubt that any 2 MCU peripherals will execute identical code block, "simultaneously."  You should note that (to my knowledge) no two independent peripherals share the same address space.  Thus your "simultaneous" objective is confounded...

Now it may be possible to have one MCU I2C peripheral route/access to all 4 slave destinations- but this method will likely "break down" upon the (multiple) Slave's colliding ACK/NAK response.  And - as they all must have the identical Slave Address to achieve any "transfer time" savings - disaster looms each/every time they are ordered to respond w/data - does it not? 

This may point to an opportunity to "broadcast" simultaneously - to multiple Slaves - via a single, common Slave Address.  (thus meeting your "speed-up" goal)  Again - this method fails upon any attempt to extract data from this "Slave Cluster."  (true unless you can devise and encode some special "extra/unique" code - to limit the Slave's answering response to one Slave at a time - we need to think further/deeper - re this approach...)

if transfer speed really is the central issue - multiple MCUs "bubble up" as one solution.

Update: (11:23 CST)  Following not guaranteed, "Good - Govt Work."  Much extra "scratch/sniff" to massage this capability from normal/customary I2C.  (my belief)  That said - slight bit-banging - along with the "breaking" of the "parallel" SDA connection and creation of an independent, return data path from each Slave to unique Master GPIO input appears to overcome both "ACK/NAK & data collision" - predictable result from tieing multiple Slave I2C devices to single Master I2C port.   Again - this "fast/furious invented" method sees a single Master I2C port routed to 4 Slaves (per normal I2C convention) but employs a logic gate to "free each Slave SDA line from parallel Slave connection when Slave TX is desired - and which captures and returns each slave's output data to 4 non I2C, Master MCU GPIO inputs.  Key to speed-up via Slave Parallel "answer/transmit" - these 4 new, again non-I2C inputs - may be read in parallel (via Master I2C clock or alternate) - achieving significant "speed-up." 

Method may work as all Master command outputs are issued "simultaneously" (in parallel) to the 4 interconnected Slaves - from a single I2C Master!  Master then receives multiple Slave response via different, non I2C GPIO inputs - clocked commonly via SCL - and again "read" in parallel.  (i.e. said Slave return data appears on Master's common port - thus read simultaneously)  (repettion deliberate - to reinforce & aid possible challenge...) 

Central in this new/proposed technique is a method to "break the parallel SDA connection @ each Slave - in use while Master transmits" and create a unique data path for Slave's answer/transmit SDA back to Master's 4 non-I2C, GPIO inputs.

Benefits of this (back of napkin - quick/dirty) approach maximized when Master is able to transfer identical commands & data to Slaves in parallel.  (note:  slaves may exceed the 4 w/in poster's example)  Should each transfer to a Slave be unique - broadcast benefits quickly erode -  your "package/content" description did not anticipate nor reveal this aspect w/in your RFP... 

Update 2: (13:37 CST) Upon lunch - bit more reflection - SPI enabling legitimate, far faster, bi-directional (duplex/simultaneous write/read) data transfer may prove superior.  Same single Master - multiple Slaves - but (maybe) single CS routed to all Slaves - w/unique Slave data paths (MISO) between each Slave and single Master.  (same GPIO input Port in use @ Master to receive this "massaged" parallel data from the bulk slaves.  These multiple, parallel Slave reads must be "bit-bang" managed (via SPI clock).  Suspect the SPI clock may be routed to a free input - triggers an interrupt which "reads" all Slave outputs in single go!

SPI's in-built duplex nature - and the far higher clock rate - raise the potential speed pay-off via this approach.  And again - ability to broadcast a common message/command to all Slaves - via single transfer - yields the largest, speed-reducing pay-back...

Thank you very much for the detailed possible solutions.
As per your suggestions we think that using SPI could be the best option.
Regarding the simultaneously communication,
lesser delay between the multiple slave communication would be a proper statement.

This application may not require the parallel communication but,
we need to read the slave data as early as possible.

We shall try to implement your solution with SPI, but it seems little bit complicated,
please let me know if there is any reference point or sample code
about controlling multiple SPI slaves.

Thank you - appreciate your comments.

SPI being far faster - avoiding any/all dreaded "ACK/NAK" management - jumped out!  (after a mere hour or so)

"Little bit complicated" (to be kind) - realized that a neat diagram (as you provided) would assist - waited till any interest/challenge arrived.

Buried today - but small tech-biz enjoys few weekends - will further detail that time-slot...

Your ability to "broadcast common commands" (Master to parallel connected, multiple SPI remotes) overlaps my special interest - creates the largest speed gain - and has not received your comment.  Would you be so good as to confirm that you can indeed, "Order multiple of your SPI Slaves into some common operation - via the exact same data/command - sent simultaneously (your word) to multiple, parallel connected Slave SPI devices?" 

Your feedback - this detailed issue (just described) strongly impacts - thus must precede further thought/preparation...posting...