> De là à faire du open hard comme il en existe que de rares examples, il n'y > a qu'un pas qui n'est pas si terrible que ça. > Imagine tu plante sur le cross-bar un système fifo pour les différents bus > que tu peut accéder de façon multiplexé depuis les cartes (un connecteur > 4x64 pin + signaux et peu crédible). Sur les cartes tu plante un > convertisseur serie -> parallèle et un autre parallèle -> serie, le côté > serie branché sur un circuit d'interface physique au réseau et de l'autre > tu plante des mémoires fifo d'IDT (Integrated device technologie) et une > mémoire à double accés pour le bus PCI. Tu chapaute ceci par un où deux PLC > de d'ALTERA ou de XILINK et un proceseur avec beaucoup de péche > (http://e-www.motorola.com/webapp/sps/site/taxonomy.jsp?nodeId=01M0ylsDFTQ) > et son entourage de ram statique, mem flash, quartz etc. Naturelement tout > le firmare en flash. Avec ça t'est capable de traiter quasiement n'inporte > quelle signaux et tu est extrainement souple au niveau du firmware. Le > problème c'est le temps CPU disponible pour le traitement. Si tu utilise > des convertisseur s-p de 64 bits tu doit quand même traiter un groupe de 64 > bits tout les 16 ns , pas possible. Par contre une sorte de mini cross-bar > entre les mémoires fifo du cross-bar inter cartes et celles faisant tampon > avec l'extérieur et qu'un transfer sur le mini cross-bar puisse fonctionner > en parallèle avec le traitement du processeur. Ceci t'offre le temps de > remplissage des tampons pour traité l'entête des paquets. > C'est sur que là il faut oublier le C et passé à l'assembleur mais cela > doit être possible si tu ne doit pas traiter de paquets trop petit. De plus > le système de clock recovery devrai être tactique. > Pour avoir une idée j'ai trouvé un schèma partielle à l'adresse > http://www.centurysys.co.jp/english/oc12/S0641_02.pdf mais il doit en > exister d'autre qui pourait donner de bonnes idée. > Bon la j'arrête le délire. Remarque c'est le genre de projet qui me boterai > pas mal hystoire de me changer du train-train cotidien. Persone ne veus > faire une startup par hazard ?
humm ton design, c'est bien joli, un peu sapin de noel, un peu beaucoup meme. jusqu'a 1Gbps de debit total, aucune raison de prendre autre chose que PCI 64bit comme bus, pas de crossbar. au dessus, ca devient du tres haut de gamme, jusque a peu reserver au design entierement proprietaire. desormais plus, les network processor et les crossbar switch sous forme de circuits integre 'standard' commence a exister, et des modules tout cuit comme j'ai indique dans les URL. mettre un crossbar switch comme fond de panier, alors que c'est encore un cpu central qui commnute, ca n'a pas de sens car le cpu serait des le depart le goulet d'etranglement. en gros: crossbar switch implique soit un traitement des paquet en hardware dedie, ou en network processor. reciproquement, un design avec un CPU central ne merite guere plus qu'un bus passif (ou evt. plusieurs) tout a fait standard. le probleme hardware est resolu. c'est le but, le logiciel est deja un sacre bordel a gerer (cf. grandeur et decadence de Cisco system). un truc vraiment passionant est d'imaginer faire tourner des morceaux de linux sur des network processors. mais bon, encore une fois, pour 1Mbps de debit, c'est un peu lourd comme solution :))) aplus > A+ > Martial -- Philippe Strauss http://philou.ch/ L'indifférence est le plus grand risque de notre temps, la forme civilisée de la cruauté. -- Zenta Maurina -- -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
