Quelques questions techniques concernant le SATA, PCI et AHCI

Notions d'interface et de protocole

Le problème exposé dans ce sujet a été résolu.

Salut les Clémentines :)

Je viens tout juste de m’inscrire sur le forum et je tiens tout d’abord à remercier la communauté pour le travail monstrueux que vous ne cessez d’accomplir. Un grand merci pour votre altruisme ! Bravo également au staff pour avoir surmonté les nombreuses épreuves qui ce sont dressées sur votre chemin. :)
En toute sincérité, j’aimerais beaucoup me joindre à vous et faire profiter de mes connaissances mais mon statut d’étudiant en classe préparatoire et mon rôle de modérateur sur un autre forum ne me le permettent malheureusement pas. :(
J’ai d’ailleurs déjà rédigé quelques tutoriels sur le forum du Crabeinfo.net. Si vous pensez qu’ils peuvent intéresser je peux éventuellement les poster ici (en les modifiant suffisamment pour être en accord avec la ligne éditoriale de Zds)

Bref, je suis actuellement en train de rédiger un tutoriel qui vise à expliquer les notions de bus, d’interface, de port et de protocole. Une seconde partie est consacrée aux interfaces et protocoles en lien avec les disques durs. Pour être le plus précis et juste possible je me suis beaucoup renseigné, tant sur les sites anglais (la langue de Shakespeare ne me fait pas peur !) que français. Le soucis c’est qu’à vouloir trop creuser l’affaire, je me suis retrouvé à me poser des questions sans pouvoir trouver de réponse(s)qui me convenai(en)t…

Bon, voici les questions car j’ai l’impression que je parle trop :

1) Le bus PCIe et le bus SATA utilisant tous les deux une liaison en série qu’est ce qui fait que concrètement le PCIe est plus rapide que le SATA ? Un port PCIe x4, par exemple, utilise 4 lignes de transmission en série. Comment le bus SATA gère t-il ses lignes de transmission ?

2) J’ai lu sur un forum anglais ceci mais j’ai du mal à comprendre le sens de la deuxième partie de la phrase :

A bus is a specific kind of interface and it uses an implementation of some protocol to manage communication going through itself, so the CPU knows what to say at what time to access memory and the memory knows how to reply with data when it is requested

3) C’est la question qui me préoccupe le plus :/
L’AHCI c’est quoi ? D’après son nom on pourrait penser qu’il s’agit d’une interface physique mais en même temps j’ai lu à droite à gauche qu’il s’agissait d’un protocole. Pour moi c’est un protocole car je n’ai jamais vu de port AHCI ou quoi que ce soit. Si un disque dur est connecté sur un port SATA, j’ai le choix (depuis le BIOS) entre 3 modes d’opération : AHCI, IDE (il ne s’agit que d’une émulation à vrai dire) et RAID. Déjà c’est quoi qu’il entendent par mode d’opération ?

Sur le wiki français ils parlent de mécanisme matériel. What !? o_O

D’autre part j’ai toujours pensé que l’AHCI pour le SATA était ce qu’est le NVME pour le PCIe (des protocoles donc), aurais-je tort ?

Tout élément de réponse (même s’il ne s’agit que d’un zeste) est le bienvenue :)

+4 -0

1) Basiquement une des principales différences c’est que le PCIE est un bus sur la carte mère et ses périphériques, qui est très court et sur un médium rigide qui peut être contraint facilement : les circuits imprimés d’un ordinateur sont très précisément construits et peuvent "tenir" de très hautes fréquences. Le SATA, lui, passe par un câble qui peut faire un mètre de long ou plus, avoir des rallonges, est très flexible et passe dans un environnement hostile plein de parasites. Forcément, le PCIE peut utiliser des signaux à une fréquence largement supérieure, de l’ordre des GHz, ce qui permet l’ordre de grandeur de plus en vitesse.

2) En gros ça explique ce qu’est un protocole : une spécification qui dit comment communiquer avec l’autre.

3) L’AHCI c’est le protocole entre le processeur et le driver SATA sur la carte mère. On n’utilise pas directement du SATA, on utilise de l’AHCI, ou l’émulation IDE.

Salut @Stranger et merci pour ta réponse.

[…] le PCIE est un bus sur la carte mère et ses périphériques, qui est très court et sur un médium rigide qui peut être contraint facilement : les circuits imprimés d’un ordinateur sont très précisément construits et peuvent "tenir" de très hautes fréquences. Le SATA, lui, passe par un câble qui peut faire un mètre de long ou plus […] Forcément, le PCIE peut utiliser des signaux à une fréquence largement supérieure, de l’ordre des GHz, ce qui permet l’ordre de grandeur de plus en vitesse.

Stranger

D’accord. Donc en fait le bus SATA est limité "techniquement" en fréquence. La flexibilité et la longueur plus importante de la connectique rend impossible l’utilisation des signaux à très haute fréquence.

En gros ça explique ce qu’est un protocole : une spécification qui dit comment communiquer avec l’autre.

Stranger

Ça c’est la première partie de la phrase et je l’avais comprise :)
Ce qui me pose problème c’est ça :

[…] so the CPU knows what to say at what time to access memory and the memory knows how to reply with data when it is requested


3) L’AHCI c’est le protocole entre le processeur et le driver SATA sur la carte mère. On n’utilise pas directement du SATA, on utilise de l’AHCI, ou l’émulation IDE.

Stranger

Bon déjà je suis rassuré. L’AHCI est bien un protocole. Du coup sur le wiki c’est foireux…

En revanche, je ne comprends pas très bien ce que tu veux dire dans ta deuxième phrase.
Pour moi, on connecte un disque dur sur un port SATA et le protocole AHCI permet d’améliorer les fonctionnalités du SATA. Concernant l’IDE/PATA, il s’agit d’un autre type d’interface qui peut être émulé en utilisant un port SATA.
Pourquoi dis-tu qu’on n’utilise pas directement du SATA ? Vu qu’on branche un disque dur sur un port SATA, on l’utilise bien non ?

La deuxième partie du point 2 est juste une description de ce qu’est un protocole. C’est de la diatribe de Wikipédien qui ne veut rien dire à part "quand on utilise un protocole on sait à quelle adresse écrire les choses, lol".

Pour l’AHCI, c’est simple, le processeur voit une interface AHCI, et non une interface SATA. Le SATA est une interface hardware derrière. C’est un peu comme utiliser un socket TCP par dessus Ethernet, en réseau - tu vois TCP, en utilisant Ethernet. On dit "le processeur" comme si c’était une entité atomique mais tu as une carte mère avec des circuits d’interface, un chipset, et un processeur, et tout ça communique par différents bus, il n’y a pas une prise SATA sur le processeur…

La deuxième partie du point 2 est juste une description de ce qu’est un protocole. C’est de la diatribe de Wikipédien qui ne veut rien dire à part "quand on utilise un protocole on sait à quelle adresse écrire les choses, lol".

Stranger

Ouais diatribe c’est pas le mot adapté mais je vois ce que tu veux dire ^^

Pour l’AHCI, c’est simple, le processeur voit une interface AHCI, et non une interface SATA. Le SATA est une interface hardware derrière. C’est un peu comme utiliser un socket TCP par dessus Ethernet, en réseau - tu vois TCP, en utilisant Ethernet. On dit "le processeur" comme si c’était une entité atomique mais tu as une carte mère avec des circuits d’interface, un chipset, et un processeur, et tout ça communique par différents bus, il n’y a pas une prise SATA sur le processeur…

Stranger

Ce que j’ai du mal à comprendre c’est que si l’AHCI est un protocole, ça ne peut pas être une interface. Par définition, un protocole ne peut pas être une interface non ? D’ailleurs, un protocole ne peut pas être un truc physique. Si c’est bien le cas, alors il faut modifier la définition sur le wiki français parce que c’est pas clair leur truc…

Oui, de la même façon TCP est un protocole donc immatériel.

Un protocole, une interface, une spécification : tout ça c’est la même chose. Est-ce que I²C est un protocole ou une interface matérielle ? C’est les deux - c’est un protocole de communication, qui est typiquement implémenté directement de façon matérielle. Et c’est une interface dans la mesure où tu discute avec un appareil à travers le bus. AHCI est tout ça à la fois, c’est une spécification qui recouvre une interface, un protocole, un matériel.

En gros, AHCI au niveau matériel c’est un pont entre le processeur (via PCI) et un disque (via SATA). Au niveau logiciel c’est une interface avec des registres, des commandes, etc. C’est donc un composant physique présent dans la carte mère ou le package du processeur, interfacé avec le processeur lui-même via PCI, pour lequel on écrit un driver, et qui communique à son tour avec le périphérique via le bus SATA.

Franchement, c’est une spécificité d’architecture assez technique qui intéresse Intel, AMD et les développeurs d’OS. Là où tu auras le plus de réponses c’est encore en lisant la spec, parce que je n’en sais guère plus. Wikipédia est souvent une mauvaise source pour les sujets "propriétaires" comme ça - AHCI c’est une norme Intel que le reste du monde suit.

Un protocole, une interface, une spécification : tout ça c’est la même chose. Est-ce que I²C est un protocole ou une interface matérielle ? C’est les deux - c’est un protocole de communication, qui est typiquement implémenté directement de façon matérielle. Et c’est une interface dans la mesure où tu discute avec un appareil à travers le bus. AHCI est tout ça à la fois, c’est une spécification qui recouvre une interface, un protocole, un matériel.

Stranger

Arf ! Moi qui pensais avoir compris ce qu’était un protocole… Alors comme ça un protocole peut aussi être implanté physiquement ? Je croyais que du moment que c’était par définition un ensemble de règles convenues pour faciliter la communication (transfert de données), ça ne pouvait pas être matériel.
C’est assez abstrait comme notion quand même… Il n’empêche que fondamentalement un port (donc une interface) n’est pas la même chose qu’un protocole non ? Pas évident d’avoir les idées claires ^^

En gros, AHCI au niveau matériel c’est un pont entre le processeur (via PCI) et un disque (via SATA). Au niveau logiciel c’est une interface avec des registres, des commandes, etc. C’est donc un composant physique présent dans la carte mère ou le package du processeur, interfacé avec le processeur lui-même via PCI, pour lequel on écrit un driver, et qui communique à son tour avec le périphérique via le bus SATA.

Merci. Ton explication est très claire :)

Franchement, c’est une spécificité d’architecture assez technique qui intéresse Intel, AMD et les développeurs d’OS. Là où tu auras le plus de réponses c’est encore en lisant la spec, parce que je n’en sais guère plus. Wikipédia est souvent une mauvaise source pour les sujets "propriétaires" comme ça - AHCI c’est une norme Intel que le reste du monde suit.

Grace à toi j’ai bien compris ce qu’était le AHCI. Il faut maintenant que j’arrive à me faire à l’idée qu’un protocole peut être matériel… (ça ne colle pas avec la définition… ^^)

+0 -0

Salut,

Les mots interface, protocole, spécifications ne sont pas mutuellement exclusifs.

Une interface, de manière très générale, est ce qui sépare deux entités différentes. Par exemple, un connecteur PCIe est une interface physique entre la carte mère et le périphérique. En programmation orientée objet, une interface désigne ce qui connecte l’objet au reste du programme.

Un protocole est simplement une manière de faire les choses. Un protocole expérimental désigne la suite des opérations à effectuer pour obtenir un résultat donné. Le protocole diplomatique dicte comment se comporter pour les relations internationales. Un protocole de communication désigne comment deux entités doivent échanger des informations entre elles.

Une spécification est une description précise de quelque chose. Tu peux spécifier ce que tu veux : un procédé de fabrication, un système de communication, un protocole, les caractéristiques d’un matériau de construction, etc.

En fin de compte, tu peux écrire une spécification qui décrit un protocole de communication permettant à deux systèmes (un CPU et un disque dur par exemple) de s’interfacer.

Salut @Aabu,

Un protocole est simplement une manière de faire les choses. […] Un protocole de communication désigne comment deux entités doivent échanger des informations entre elles.

Aabu

Oui je suis d’accord mais, par définition, une manière de faire les choses n’est pas un objet. La réponse à la question qui est ce qui dicte comment deux entités doivent échanger des informations entre elles ? n’est pas pas un objet non plus. En fait la seule chose qui me turlupine encore c’est comment on considérer un protocole comme étant un élément matériel. Parce qu’au final, un protocole c’est un peu comme une recette de cuisine non ?

En fin de compte, tu peux écrire une spécification qui décrit un protocole de communication permettant à deux systèmes (un CPU et un disque dur par exemple) de s’interfacer.

Oui, je te suis mais de quelle façon un protocole permet-il à 2 systèmes de s’interfacer ? Un port (pas dans le sens "port TCP/IP") est un élément matériel qui permet de brancher des périphériques. C’est donc une interface.
Un bus désigne l’ensemble des liaisons physiques (câbles, conducteurs électriques gravés sur les circuits imprimés…) permettant aux différents composants d’un ordinateur de communiquer entre eux. Il s’agit donc bien d’une interface.
Mais un protocole ? Je ne vois vraiment pas en quoi cela pourrait être matériel.

D’ailleurs le protocole NVME est clairement immatériel non ?

@Stranger et @Aabu,
J’espère que je ne vous gonfle pas trop avec ce genre de questionnement. Merci pour votre aide en tout cas :)

Disons que si un protocole est fondamentalement quelque chose d’abstrait, son implémentation peut être logicielle, ou matérielle.

D’un point de vue fondamentale encore, le matériel et le logiciel c’est la même chose, la seule différence étant la forme de l’implémentation. Rien ne sous empêche de graver Linux sur Silicium pour de meilleures performances (mais plus difficile à faire / corriger, coûteux).

+1 -0

Effectivement, un protocole est abstrait, et souvent, il n’est pas précisé si certaines parties sont réalisées en logiciel ou en matériel. C’est à l’implémentation de décider.

En vérité, bien souvent, la frontière entre logiciel et matériel n’est pas si intéressante au très bas niveau. Il est pour moi utile de voir le logiciel comme une configuration du matériel. Au bas niveau, le logiciel est extrêmement lié au matériel, parce que ce que tu fais dépend des périphériques disponibles.

Par exemple, dans un produit pour le travail, le microcontrolleur possède un périphérique interne pour décoder directement certaines informations depuis le bus de communication. Il n’est pas nécessaire de coder quoi que ce soit. Le logiciel se contente de lire une adresse mémoire pour récupérer l’information. Par contre, le matériel de développement du même produit est beaucoup plus flexible (et cher), et la lecture du signal brut est faite matériellement, mais l’interprétation est faite essentiellement par le logiciel.

On a en fait d’un côté une électronique spécifique, rapide, pas flexible et pas chère et de l’autre une électronique très générale, très rapide, très flexible et beaucoup plus chère.

L’exemple extrême de la vision "le logiciel est une configuration du matériel" est le FPGA. Grossièrement, c’est un circuit logique entièrement programmable. Cela signifie que ce tu programme se retrouve matériellement dans le composant.

D’accord. C’est beaucoup plus clair maintenant. Merci :)
Il me reste juste 3 (petites) questions :

1) Le protocole AHCI a été à la fois implanté matériellement et logiciellement ou simplement matériellement ?

2) Le protocole NVME est simplement logiciel de ce que j’ai compris. Vous confirmez ?

3) @Stranger et @Aabu
Dans un précédent message (Stranger) tu disais qu’une interface et un protocole était la même chose. D’après @Aabu il y a quand même une différence. C’est le protocole qui permet d’interfacer, ce n’est pas une interface lui-même.
Qu’en est-il du coup ?

+0 -0

Une interface, c’est ce qui fait la liaison entre deux choses. C’est très abstrait et surtout cela s’incarne à plusieurs niveaux.

Par exemple, tu auras peut-être dans le futur une voiture électrique. Quand tu la recharges, tu la connectes à une borne de recharge. L’interface entre la voiture et la borne est constituée :

  • du support physique, ici la prise, avec une forme particulière de connecteur et de câblage,
  • des caractéristiques électriques (tension nominale, courant maximal autorisé, etc.),
  • un protocole de communication, qui gère la vitesse de charge en fonction de l’état de la batterie, des capacités de ma borne et de la voiture etc.

Si tu es constructeur automobile et que tu veux que ta nouvelle voiture s’interface avec les bornes existantes, tu vas devoir respecter tous les aspects de l’interface borne-voiture : bonne prise, bon câblage, tension et courant maximaux supportés, et le bon protocole pour discuter avec la borne. Si tu manques une des exigences, ça ne marche pas : la prise ne rentre pas c’est mort, les fusibles explosent c’est mort, la borne n’arrive pas à communiquer avec la voiture, c’est mort.

C’est pareil avec les interfaces informatiques. Si tu veux pouvoir écrire sur un disque dur, il faut une interface avec le bon connecteur, les bons niveaux de tension, que les bits se suivent dans le bon ordre pour avoir du sens, etc.

Finalement, les protocoles de communication ont toujours à voir avec les interfaces, parce que tu échanges de l’information entre deux entités différentes, et donc tu les interfaces. Par contre, une interface n’est pas forcément liée à une protocole. Par exemple, sur une prise électrique à la maison, il n’y a pas de protocole lié à l’interface : tu branches c’est tout.

Je débarque un peu après le début de la bataille, mais hier j’étais trop occupé à boire des bières (c’est Stranger qui m’a parlé du topic).

Ce qu’il en ressort de ces premiers échanges, c’est qu’on joue beaucoup sur le vocabulaire : protocole, interface, bus, etc. Sauf que ce n’est jamais explicitement défini et de toute façon dans la vie de tous les jours personne n’utilise parfaitement les termes.

L’autre point que j’ai remarqué c’est qu’à aucun moment non plus il y a une différence faite entre les différentes strates des bus cités : PCIe, SATA. En effet aujourd’hui les ces bus/protocoles/interfaces ne sont pas uniquement définis au niveau physique stricto census (niveau de tension par exemple) mais aussi au niveau protocolaire : de plus en plus de bus intègre une couche de données permettant la réalisation des transactions, de manière invisible pour les couches logicielles hautes.

(Bon finalement Aabu réagi sur ce point)

1) Le bus PCIe et le bus SATA utilisant tous les deux une liaison en série qu’est ce qui fait que concrètement le PCIe est plus rapide que le SATA ? Un port PCIe x4, par exemple, utilise 4 lignes de transmission en série. Comment le bus SATA gère t-il ses lignes de transmission ?

2) J’ai lu sur un forum anglais ceci mais j’ai du mal à comprendre le sens de la deuxième partie de la phrase :

A bus is a specific kind of interface and it uses an implementation of some protocol to manage communication going through itself, so the CPU knows what to say at what time to access memory and the memory knows how to reply with data when it is requested

3) C’est la question qui me préoccupe le plus :/ L’AHCI c’est quoi ? D’après son nom on pourrait penser qu’il s’agit d’une interface physique mais en même temps j’ai lu à droite à gauche qu’il s’agissait d’un protocole. Pour moi c’est un protocole car je n’ai jamais vu de port AHCI ou quoi que ce soit. Si un disque dur est connecté sur un port SATA, j’ai le choix (depuis le BIOS) entre 3 modes d’opération : AHCI, IDE (il ne s’agit que d’une émulation à vrai dire) et RAID. Déjà c’est quoi qu’il entendent par mode d’opération ?

Sur le wiki français ils parlent de mécanisme matériel. What !? o_O

1) Le bus PCI express en 1x n’a pas tout le temps été plus rapide que le SATA. En 2004 sort le SATA 3Gbps (300MB/s). Le PCI express 1.0 culmine à 250MB/s jusqu’à la sortie du PCIe v2.0 en 2007 qui monte à 500MB/s.
Le SATA 6Gbps (600MB/s) sort en 2009 et le PCIe v3.0 (984MB/s) en 2010.

Néanmoins les deux bus utilise le même principe 2 paires différentielles en full duplex (une TX et une RX). Si au début les deux protocoles utilisent un codage 8b/10b impliquant un overhead de 20%, à partir du PCIe v3.0 ce dernier passe au codage 128b/130b ce qui réduit l’overhead et donc augmente la bande passante utile (d’où le 984MB et non un chiffre rond). Le SATA reste sur le 8b/10b pour le moment.

Enfin il y a une question de besoin aussi. Ce qui entraîne les évolutions du PCIe c’est le besoin de bande passante supplémentaire de la part des carte graphiques et cartes de calcul. Le SATA sert uniquement aux disques durs et jusqu’à l’avènement des SSD les 6Gbps étaient rarement occupés à 100%. Aujourd’hui les SSD sont capables d’utiliser pleinement la bande passante et même plus et on voit le développement de SSD sur PCIexpress, permettant un débit plus important.

2) Un bus n’est pas qu’une ligne électrique. Aujourd’hui l’USB, le PCIe, le SATA, etc. implémentent du logiciel (très) bas niveau pour gérer les transactions, sans action externe.

3) Tout est expliqué dans la norme qu’à donné Stranger.

1) Le protocole AHCI a été à la fois implanté matériellement et logiciellement ou simplement matériellement ?

2) Le protocole NVME est simplement logiciel de ce que j’ai compris. Vous confirmez ?

Mreve

1)Ca ne veut rien dire implémenté matériellement et logiciellement. Même si on parle de FPGA et donc de la possibilité de tout faire en dur, en théorie tu n’a pas à connaître l’implémentation.
Par exemple j’ai travaillé sur l’AFDX qui est un dérivé de l’Ethernet. Une société proposait des puces gérant un certain nombre de liens en RX et en TX. Mais un des clients cherchait à faire surtout du RX et donc ils ont implémenté la gestion du protocole sur un processeur en soft.

De plus aujourd’hui via des registres et même des micro-codes on peut très bien modifier le fonctionnement d’une puce. Par exemple les contrôleurs DDR peuvent être implémentés en dur (il fait partie de la puce) comme en soft (on le fait avec les portes) sur un FPGA et on est capable de le configurer pour fixer la fréquence de la RAM par exemple.

Une norme spécifie un protocole, des contraintes à respecter, mais dans la mesure du possible n’indique jamais l’implémentation, cette dernière doit être libre.

2) Le NVME est semblable au AHCI, donc l’implémentation est la discrétion de celui qui l’utilise.

Je débarque un peu après le début de la bataille, mais hier j’étais trop occupé à boire des bières (c’est Stranger qui m’a parlé du topic).

zeql

Je ne m’attendais pas à ce que mon topic soit mentionné dans une quelconque autre discussion (IRL ou non). D’autant que j’ai essayé d’imaginer la conversation. Ça m’a bien fait sourire…

Ce qu’il en ressort de ces premiers échanges, c’est qu’on joue beaucoup sur le vocabulaire : protocole, interface, bus, etc. Sauf que ce n’est jamais explicitement défini et de toute façon dans la vie de tous les jours personne n’utilise parfaitement les termes.

Mouais et c’est bien le genre de truc que je n’aime pas… employer des mots qui ont une définition obscure. Mais je comprends que ça ne soit pas évident.

1) Ca ne veut rien dire implémenté matériellement et logiciellement. Même si on parle de FPGA et donc de la possibilité de tout faire en dur, en théorie tu n’a pas à connaître l’implémentation. Par exemple j’ai travaillé sur l’AFDX qui est un dérivé de l’Ethernet. Une société proposait des puces gérant un certain nombre de liens en RX et en TX. Mais un des clients cherchait à faire surtout du RX et donc ils ont implémenté la gestion du protocole sur un processeur en soft. […]
Une norme spécifie un protocole, des contraintes à respecter, mais dans la mesure du possible n’indique jamais l’implémentation, cette dernière doit être libre.

Attends je ne comprends pas. Tu dis que implémenter matériellement ou logiciellement ne veut rien dire mais plus loin tu parles d’implémentation en soft. Le protocole AHCI (pas forcément dans son entier) ne peut pas être considéré comme implanté physiquement sur le port SATA ? (ptêt que je raconte une bêtise là…)

2) Le NVME est semblable au AHCI, donc l’implémentation est la discrétion de celui qui l’utilise.

Mais tout le monde utilise le NVME et le AHCI de la même façon non ? o_O

Merci pour tes précisions en tout cas.

1) Ca ne veut rien dire implémenté matériellement et logiciellement. Même si on parle de FPGA et donc de la possibilité de tout faire en dur, en théorie tu n’a pas à connaître l’implémentation. Par exemple j’ai travaillé sur l’AFDX qui est un dérivé de l’Ethernet. Une société proposait des puces gérant un certain nombre de liens en RX et en TX. Mais un des clients cherchait à faire surtout du RX et donc ils ont implémenté la gestion du protocole sur un processeur en soft. […]
Une norme spécifie un protocole, des contraintes à respecter, mais dans la mesure du possible n’indique jamais l’implémentation, cette dernière doit être libre.

Attends je ne comprends pas. Tu dis que implémenter matériellement ou logiciellement ne veut rien dire mais plus loin tu parles d’implémentation en soft. Le protocole AHCI (pas forcément dans son entier) ne peut pas être considéré comme implanté physiquement sur le port SATA ? (ptêt que je raconte une bêtise là…)

Mreve

Oui l’exemple d’un contrôleur DDR en soft ou en hard justement, pour moi, montre que l’implémentation on s’en fout : il fonctionne de la même façon car il respecte les spécifications des normes des mémoires.
De même pour l’AFDX : le protocole a été implémenté en hard sur une puce mais l’a aussi été en soft sur un processeur, dans les deux cas ça fonctionne parfaitement ! Donc l’implémentation hard ou soft d’un protocole (sachant que pour moi le protocole concerne l’algorithme pour la gestion de l’interface)

Et c’est ce que je dit à la fin : une norme (qui en général spécifie un protocole, une interface et/ou un bus) n’a pas vocation à donner l’implémentation d’une spécification. L’implémentation doit être libre.

J’en discutais encore aujourd’hui sur l’Ethernet à propos du fonctionnement sans transformateur. La norme Ethernet ne dit pas qu’il faut utiliser un transformateur pour assurer une isolation galvanique. Non elle indique des niveaux de tensions (1500V pendant 60s par exemple) à supporter. Un des moyens simple et efficace est l’utilisation d’un transformateur, mais on peut très bien utiliser des condensateurs en série.

De même on entend souvent dire que la longueur d’un cable Ethernet c’est 100m maximum. Et bien non, la norme ne spécifie pas de longueur maximale mais un délai de propagation maximum, qui dans le cas d’un cable RJ45 classique (ce qui ne veut rien dire au passage) correspond grosso modo à 100m. Mais si on utilise un cable plus performant (qui atténue moins le signal électrique) on peut très bien faire une longueur de 120 ou 130m et respecter la norme Ethernet.

Pour revenir sur ma phrase en gras, voici un schéma de la norme Ethernet sur le 10G :

Archi 10G

La partie physique est spécifique à une interface. Ici dans le cas de l’Ethernet 10G, 4 interfaces sont possibles : 10GBase-W, 10GBase-R, 10GBase-KR et 10GBase-T.
Le "protocole" c’est la couche OSI 2 (Data Link) : Mac + LLC.

Pour t’embrouiller un peu plus l’esprit, y compris à l’intérieur de la partie "PHY" il y a une partie protocole.

Image utilisateur

Ici on peut voir les trois partie d’un PHY : le PCS, le PMA et le PMD et leur relation. On peut voir des noms de signaux physiques électriques (XGMII et MDI en haut et en bas) ainsi que des noms internes qui lient les différentes parties.

Et voici le diagramme d’état du PCS :

Image utilisateur

Et ça, ça s’implémente en hard comme en soft, c’est un algorithme. Et c’est pour moi le protocole du PCS : les règles à respecter pour communiquer avec lui (enfin faut lire la norme pour les avoir toutes, le diagramme n’étant qu’un résumé).

2) Le NVME est semblable au AHCI, donc l’implémentation est la discrétion de celui qui l’utilise.

Mais tout le monde utilise le NVME et le AHCI de la même façon non ? o_O

Merci pour tes précisions en tout cas.

Mreve

Ce que je veux dire c’est que le NVME est une norme semblable au AHCI : ça définit une manière d’accès aux données d’un disque dur.

+1 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte