首页 > > > SEMI E04 - 0699.pdf

SEMI E04 - 0699.pdf

SEMI E04 - 0699.pdf

上传者: alai7150 2014-03-30 评分1 评论0 下载1 收藏10 阅读量29 暂无简介 简介 举报

简介:本文档为《SEMI E04 - 0699pdf》,可适用于电子通讯领域,主题内容包含SEMIESEMI,SEMIESEMIEQUIPMENTCOMMUNICATIONSSTANDARDMESSAGETRANSFER(SECSI)Th符等。

SEMIE4-0699SEMI1980,19991SEMIE4-0699SEMIEQUIPMENTCOMMUNICATIONSSTANDARD1MESSAGETRANSFER(SECS-I)ThisstandardwastechnicallyapprovedbytheGlobalInformation&ControlCommitteeandisthedirectresponsibilityoftheNorthAmericanInformation&ControlCommittee.CurrenteditionapprovedbytheNorthAmericanRegionalStandardsCommitteeonFebruary28,1999.InitiallyavailableonSEMIOnLineMay1999;tobepublishedJune1999.Originallypublishedin1980;previouslypublishedJanuary1999.1Introduction1.1RevisionHistory—ThisisthefirstmajorrevisionsincetheoriginalreleaseofSECS-Iin1980.VerylittleoftheoriginalintentofSECS-Ihasbeenaltered,althoughthereareafewsignificantadditions.ThechangesaresummarizedinAppendix1.ThisspecificationhasbeendevelopedincooperationwiththeJapanElectronicIndustryDevelopmentAssociationCommittee12onEquipmentCommunications.1.2Scope—TheSECS-Istandarddefinesacommunicationinterfacesuitablefortheexchangeofmessagesbetweensemiconductorprocessingequipmentandahost.Semiconductorprocessingequipmentincludesequipmentintendedforwafermanufacturing,waferprocessing,processmeasuring,assemblyandpackaging.Ahostisacomputerornetworkofcomputerswhichexchangeinformationwiththeequipmenttoaccomplishmanufacturing.Thisstandardincludesthedescriptionofthephysicalconnector,signallevels,datarateandlogicalprotocolsrequiredtoexchangemessagesbetweenthehostandequipmentoveraserialpoint-to-pointdatapath.Thisstandarddoesnotdefinethedatacontainedwithinamessage.ThemeaningofmessagesmustbedeterminedthroughsomemessagecontentstandardsuchasSEMIEquipmentCommunicationsStandardE5(SECS-II).1.3Intent—Thisstandardprovidesameansforindependentmanufacturerstoproduceequipmentand/orhostswhichcanbeconnectedwithoutrequiringspecificknowledgeofeachother.1.3.1LayeredProtocol—TheSECS-Iprotocolcanbethoughtofasalayeredprotocolusedforpoint-to-pointcommunication.ThelevelswithinSECS-Iarethephysicallink,blocktransferprotocol,andmessageprotocol.(SeeRelatedInformationR1-1.1.)1.3.2Speed—Itisnottheintentofthisstandardtomeetthecommunicationneedsofallpossibleapplications.Forexample,thespeedofRS-232maybeinsufficienttomeettheneedsoftransferringmassamountsofdataorprogramsinashortperiodoftime,suchasmightberequiredbyhighspeedfunctionaltestapplications.1.3.3NetworkSupport—ThemethodbywhichblocksofdataareroutedtoapieceofequipmentorfindtheirwaybacktotheproperhostapplicationisnotspecifiedbySECS-I.Inanetwork,therolesofhostandequipmentmightbeassumedbyanypartyinthenetwork.Inthissituation,oneendofthecommunicationslinkmustassumetheroleoftheequipmentandtheothertheroleofthehost.1.4ApplicableDocuments1.4.1ElectronicsIndustriesAssociationStandards1EIARS-232-C—InterfacebetweenDataTerminalEquipmentandDataCommunicationEquipmentEmployingSerialBinaryDataInterchangeEIARS-269-B—SynchronousSignalingRatesforDataTransmissionEIARS-334—SignalQualityatInterfaceBetweenDataProcessingTerminalEquipmentandSynchronousCommunicationEquipmentforSerialDataTransmissionEIARS-422—ElectricalCharacteristicsofBalancedVoltageDigitalInterfaceCircuitsEIARS-423—ElectricalCharacteristicsofUnbalancedVoltageDigitalInterfaceCircuits1.4.2EuropeanComputerManufacturingAssociation2ECMA/TC24/82/18—"NetworkLayerPrinciples,"FinalDraft(April,1982)1.4.3JapaneseIndustrialStandardsCommittees3JISC6361—"TheInterfacebetweenDataCircuitTerminatingEquipment(DCE)andDataTerminalEquipment(DTE)(25-pinInterface)"1.4.4InternationalOrganizationforStandardization41EIAEngineeringDepartment,StandardsSalesOffice,2001EyeStreet,N.W.,Washington,D.C.200062EuropeanComputerManufacturingAssociation,114RueduRhone,1204Geneva,Switzerland3JapaneseStandardsAssociation,1-24,Akasaka4Chome,Minato-ku,Tokyo107,Japan4ANSI,1430Broadway,NewYork,NY10018SEMIE4-0699SEMI1980,19992ISO2110-1980—DataCommunications,InterfaceConnectorsandPinAssignment1.4.5SEMISpecificationsSEMIE5—SEMIEquipmentCommunicationsStandard2—MessageContent(SECS-II)SEMIE6—SEMIFacilitiesInterfaceSpecificationFormat1.5OverviewofSECS-I—TheSECS-Istandarddefinespoint-to-pointcommunicationofdatautilizingasubsetoftheinternationalstandardknownintheU.S.A.asEIARS-232-CandinJapanasJISC6361fortheconnectorandvoltagelevels.Theactualtransmissionconsistsof8-bitbytessentseriallywithonestartandonestopbit.Thecommunicationisbidirectionalandasynchronous,butflowsinonedirectionatatime.Thedirectionisestablishedbyspecialcharactersandahandshake,afterwhichthedataitselfissent.Dataissentinblocksof254bytesorless.Eachblockconsistsofa10-byteheaderfollowedbydata.Amessageisacompleteunitofcommunicationinonedirectionandconsistsof1to32,767blocks.Eachblockheadercontainsinformationforidentifyingtheblockaspartofaspecificmessage.Messagesarepairedbyarequestanditsreplywhichtogetherarecalledatransaction.1.6StructureofDocument—Thisdocumentisdividedintosectionswhichcorrespondtomajoraspectsofthestandard.Thesectionsoutlinerequirementsaswellasimplicationsoftherequirements.Thestandardmaybeimplementedinavarietyofways,dependinguponthecomputerenvironmentwhereitisplaced.Implementationisnotpartofthestandard.InformationwhichmaybeusefulforimplementationisincludedintheformofRelatedInformation.2Terminology2.1Thefollowingbriefdefinitionsrefertosectionsprovidingfurtherinformation.2.1.1ACK—"CorrectReception"handshakecode.(SeeSection5.2.)2.1.2applicationsoftware—thesoftwareperformingthespecifictaskoftheequipmentorthehost.2.1.3block—headerplusupto244bytesofdata.(SeeSections1.5,6.7.)2.1.4blocklength—thenumberofbytessentintheblocktransferprotocol.(SeeSection5.6.)2.1.5blocknumber—a15-bitfieldintheheaderfornumberingblocksinamessage.(SeeSections6.7.)2.1.6character—abytesentontheSECS-Iserialline.(SeeSection4.1.)2.1.7checksum—a16-bitnumberusedtodetecttransmissionerrors.(SeeSection5.7.)2.1.8communicationfailure—afailureinthecommunicationlinkresultingfromafailedsend.(SeeSection5.4.)2.1.9deviceID—a15-bitfieldintheheaderusedtoidentifytheequipment.(SeeSection6.3.)2.1.10E-bit—abitintheheaderidentifyingthelastblockofamessage.(SeeSection6.6.)2.1.11ENQ—"RequesttoSend"handshakecode.(SeeSection5.2.)2.1.12EOT—"ReadytoReceive"handshakecode.(SeeSection5.2.)2.1.13equipment—theintelligentsystemwhichcommunicateswithahost.2.1.14expectedblock—theblockofamessagewhichisexpectedbythemessageprotocol.(SeeSection7.4.4.)2.1.15header—a10-bytedataelementusedbythemessageandtransactionprotocols.(SeeSection6.)2.1.16host—theintelligentsystemwhichcommunicateswiththeequipment.2.1.17lengthbyte—thecharacterusedtoestablishtheblocklengthduringtransmission.(SeeSection5.6.)2.1.18linecontrol—aportionoftheblocktransferprotocol.(SeeSection5.8.2.)2.1.19master—theblocktransferdesignationfortheequipment.(SeeSection5.5.)2.1.20message—acompleteunitofcommunication.(SeeSection7.)2.1.21messageID—a15-bitfieldintheheaderusedintheprocessofmessageidentification.(SeeSections6.5,7.3.1.)2.1.22multi-blockmessage—amessagesentinmorethanoneblock.(SeeSections6.7,7.2.2.)2.1.23NAK—"lncorrectReception"handshakecode.(SeeSection5.2.)2.1.24openmessage—amulti-blockmessageforwhichnotalloftheblockshavebeenreceived.(SeeSection7.4.4.)2.1.25opentransaction—atransactioninprogress.(SeeSection7.3.)2.1.26primarymessage—amessagewithanoddnumberedmessageID.Alsothefirstmessageofatransaction.(SeeSection6.5.)SEMIE4-0699SEMI1980,199932.1.27primary/secondaryattribute—theleastsignifi-cantbitofthelowermessageIDwhichindicateswhetherablockbelongstoaprimaryorsecondarymessage.2.1.28R-bit—abitintheheadersignifyingthedirectionofthemessage.(SeeSection6.2.)2.1.29receiver—theendoftheSECS-Ilinkreceivingamessage.(SeeSection5.8.4.)2.1.30reply—theparticularsecondarymessagecorrespondingtoaprimarymessage.(SeeSection7.3.)2.1.31replylinking—theprocessofformingatransactionoutofaprimaryandasecondarymessage.(SeeSection7.3.1.)2.1.32retrycount—thenumberofunsuccessfulattemptstosendablockintheblocktransferprotocol.(SeeSection5.4.)2.1.33RTY—theretrylimitorthenumberoftimestheblocktransferprotocolwillattempttoretrysendingablockbeforedeclaringafailedsend.(SeeSection5.4.)2.1.34secondarymessage—amessagewithanevennumberedmessageID.Alsothesecondmessageofatransaction.(SeeSection6.5.2.)2.1.35sender—theendoftheSECS-Ilinksendingmessage.(SeeSection5.8.3.)2.1.36slave—theblocktransferdesignationforthehost(SeeSection5.5.)2.1.37systembytes—a4-bytefieldintheheaderusedformessageidentification.(SeeSection6.8.)2.1.38T1—receiveinter-charactertimeoutintheblocktransferprotocol.(SeeSection5.3.1.)2.1.39T2—protocoltimeoutintheblocktransferprotocol.(SeeSection5.3.2.)2.1.40T3—replytimeoutinthemessageprotocol.(SeeSections5,7.3.2)2.1.41T4—inter-blocktimeoutinthemessageprotocol.(SeeSection7.4.3.)2.1.42transaction—aprimarymessageanditsassociatedsecondarymessage,ifany.(SeeSection7.3.)2.1.43W-bit—abitintheheadersignifyingthatareplyisexpected.(SeeSection6.4.)3Coupling3.1Couplingreferstothephysicalinterfaceattheequipment.Thehostwillprovidecompatiblesignalsatthispoint.Norestrictionsareimpliedforanyinterfaceotherthanforequipmentcoveredbythisstandard.3.2ElectricalInterface—TheconnectionwillincludeaserialinterfaceaccordingtoEIAStandardRS-232-CforinterfaceTypeE,fullduplexcommunication,modifiedbythedeletions,additionsandexceptionsdescribedinthissection.3.2.1Connector—Eitherthe9-pinor25-pinconnectordescribedintheEIARS232maybeused.Inthecaseofthe25-pinconnectorafemaleconnectorwillbemountedontheequipmentandamaleconnectorwillbemountedonthecablefromthehost.Inthecaseofthe9-pinconnectorthemaleconnectorwillbemountedontheequipmentandafemaleconnectorwillbemountedonthecable.Theconnectorontheequipmentwillhavefemale4-40threadedjackscrewlocks.NOTE:Suitable25-pinconnectorsknownasType"D"aresimilartoAmphenolMINRAC17serieswithjackscrewlocks.Suitable9-pinconnectorisalsoType"D"withjackscrewlocks.ItisthetypecommonlyimplementedondesktopandnotebookPCs.3.2.2SignalPins—PinsontheconnectorhavefunctionsasdefinedinTable1.Pins1,2,3,and7ofthe25-pinconnectororpins3,2,and5ofthe9-pinconnectorarerequiredforallequipmentcomplyingwithSECS-I.Whenusinga25-pinconnector,thetwopowersupplypins,18and25,areoptionalasindicated.Anyotherpins,ifused,shallcomplywiththeRS-232-Cstandard.Table1SignalConnections25-Pin9-PinRS-232-CCircuitCircuitDescription1--AAShield23BADatafromEquipment32BBDatatoEquipment75ABSignalGround18----+12to+15volts(optforthe25-pinconnector)25-----12to-15volts(optforthe25-pinconnector)3.2.3LogicLevels—Forthesignalpins2and3,thelogic1levelwillbeavoltagelessthan-3voltsandthelogic0levelwillbeavoltagegreaterthan+3volts.Voltageswillneverexceed25volts.ThesevaluescorrespondtothosespecifiedbytheRS-232-Cstandard.3.2.4PowerSupplies—Whenusinga25-pinconnector,pins18and25areoptionalpowersuppliesfordrivingexternalisolationcircuits.Whenprovided,bothshallbepresentandmustbeabletosupplyatleast50mA.(SeeRelatedInformationR1-2forexampleuse.)SEMIE4-0699SEMI1980,199943.3DataRate—Thesupporteddataratesonsignalpinsshallbe9600,4800,2400,1200,and300baud.Thesamedatarateshallapplyfordatasenttoandfromtheequipment.Thedatarateshallbecontrolledtobetterthan0.5%.(SeeRS-269-BandRS-334.)Optionalratesof19,200and150baudmaybesuppliedifdesired.3.4PhysicalMedium—TheconnectionwiththehostmayinvolveanymediumthatprovidestherequiredRS-232-Cquality,signallevelsanddatarateattheequip-mentconnector.Thequalityofsignalshouldbesuchthattheeffectivebiterrorrateislessthan110-6.Thisratecanbeachievedeasilywithhardwiredsystems.ThedistancelimitsspecifiedinRS-232-CapplyonlytosystemsusingthewiringtechniquedescribedinRS-232-C.SinceanymethodmaybeusedinSECS-IaslongasRS-232-Csignalsaresuppliedattheconnector,thedistanceandisolationisdependentuponthedesignofthephysicalmediumwhichisexternaltotheSECS-Istandard.(SeeRelatedInformationR1-2.)4CharacterStructure4.1Characters—Datawillbetransmittedorreceivedinaserialbitstreamof10bitspercharacteratoneofthespecifieddatarates.Thestandardcharacterhasonestartbit(0),8databitsandonestopbit(1).Allbittransmissionsareofthesameduration.The8databitsarenumberedfrom1to8intheordersent(seeFigure1).Thetimingbetweencharactersisasynchronouswithrespecttothedatarate.The8databitsmaybeanyarbitrarycode.Theeightdatabitswillhereafterbereferredtoasabyte.Figure1CharacterStructure4.2WeightedCodes—Forbyteshavingweightedcodes,bitoneistheleastsignificantandbiteightisthemostsignificant.Themostcommonweightedcodeisbinary.4.3Non-WeightedCodes—ForcodeswithoutnumericvaluesuchasASCII,thebitnumberswillbeusedastheentryintoastandardcodetableforinterpretationofthecode.SECS-Iperformsnoparityorotherverificationofthecontentsofindividualbytes.5BlockTransferProtocol5.1Theprocedureusedbytheseriallinetoestablishthedirectionofcommunicationandprovidetheenvironmentforpassingmessageblocksiscalledtheblocktransferprotocol.Mostoftheprotocolisaccomplishedwithahandshakeofsinglebytes.Whenbothendsofthelinetrytosendatthesametime,aconditionknownaslinecontentionexists.Theprotocolresolvescontentionbyforcingoneendoftheline,designatedastheslave(alwaysthehost),topostponeitstransmissionandenterthereceivemode.Retransmissionofblocksisusedtocorrectcommunicationerrors.TheblocktransferprotocolisshowninflowchartforminFigure2,anddescribedbelow.AdditionalinformationisalsocontainedinRelatedInformationR1-3andR1-4.5.2HandshakeBytes—ThefourstandardhandshakecodesusedintheblocktransferprotocolareshowninTable2.Thethreeletternames,ENQ,EOT,ACK,andNAKcorrespondtotheASCIIcodehavingthesamepattern.Table2HandshakeCodesNameCodeb8b7.........b1FunctionENQ00000101RequesttoSendEOT00000100ReadytoReceiveACK00000110CorrectReceptionNAK00010101IncorrectReception5.3TimeoutParameters—Timeoutsareusedtode-tectcommunicationsfailures.Atimeoutoccurswhenthemeasuredtimebetweentwoeventsexceedsapre-determinedlimit.Generally,thelengthoftimethatmustpassbeforeitcanbeassumedthatanerrorhasoc-curreddependsupontheparticularsystemsinvolved.Thetimerequiredinonesituationmightbeexcessivelylonginanother.Thus,thetimeoutvaluesmustbe"tuned"tomeettheapplication.Intheblocktransferprotocol,therearetwosituationsrequiringtimeoutval-ues.ThetwotimeoutvaluesarecalledparametersT1andT2.5.3.1Inter-CharacterTimeout,T1—Theinter-charactertimeout,T1,limitsthetimebetweenreceiptofcharacterswithinablockafterthelengthbytehasbeenreceivedanduntilthereceiptofthesecondchecksumbyte.5.3.2ProtocolTimeout,T2—Theprotocoltimeout,T2,limitsthetimebetweensendingENQandreceivingEOT,sendingEOTandreceivingthelengthbyte,andsendingthesecondchecksumbyteandreceivinganycharacter.SEMIE4-0699SEMI1980,199955.4RetryLimit,RTY—Theretrylimit,RTY,isthemaximumnumberoftimestheBlockTransferProtocolwillattempttoretrysendingablockbeforedeclaringafailedsend.(SeeSection5.8.2.)5.5Master/Slave—Themaster/slaveparameterisusedintheresolutionofcontention(seeSection5.8.2).Thehostisdesignatedastheslave.Theequipmentisdesig-natedasthemaster.Thisconventionisbasedupontheassumptionthattheequipmentislessabletostoremessagesthanthehost.5.6BlockLengths—TheunsignedintegervalueofthefirstbytesentafterreceiptofEOTisthelengthoftheblockbeingsent.Thelengthincludesallthebytessentafterthelengthbyte,excludingthe2bytesofthechecksum.ThemaximumblocklengthallowedbySECS-Iis254bytes,andtheminimumis10bytes.5.7Checksum—Thechecksumiscalculatedasthenumericsumoftheunsignedbinaryvaluesofallthebytesafterthelengthbyteandbeforethechecksuminasingleblock.Thechecksumissentas16bitsintwobytesfollowingthelastbyteoftheblockdata.Thehighordereightbitsofthechecksumwillbesentfirst,followedbythelowordereightbits.Thechecksumisusedbythereceivertocheckfortransmissionerrors.Thereceiverperformsthesamechecksumcalculationonthereceivedheaderanddata.5.8Algorithm—TheoperationoftheblocktransferprotocolisbestunderstoodbyfollowingthelogicflowinFigure2.Thisflowchartdepictstheoperationofthefivestatesoftheprotocol-Receive,Idle,SendLineControl,andCompletion.TheflowchartshowninFig-ure2isnotmeanttoimplythataparticularimplemen-tationisrequiredunderthisstandard.However,anySECS-Iblocktransferprotocolimplementationmustin-cludeallthelogicdescribedinFigure2.ThesamealgorithmisexecutedoneachendoftheSECS-Icommunicationslink.5.8.1IdleState—BothendsofthecommunicationslinkareassumedtostartintheIdlestate.TherearetwoprimaryactivitiesoftheprotocolsignifiedbythetwoexitsfromtheIdlestate.Theseare:A.SEND—amessageblockistobesent.B.RECEIVE—theotherendofthecommunicationslinkhasamessageblocktosend5.8.2LineControl—Thelinecontrolsectionestab-lishesthetransmissiondirection,resolvescontention,andhandlesretries.WhenanENQisreceivedintheIdlestate,theLineControlrespondswithanEOTiftheBlockTransferProtocolisreadytoreceive.TheBlockTransferProtocolthengoestotheReceivestate.Ifamessageblockistobesent,thenanENQissent.IfanEOTisreceivedinresponsetotheENQwithinthetimelimitT2,theBlockTransferProtocolgoestotheSendstate.5.8.2.1IftheslavereceivesanENQinresponsetotheENQ,contentionhasoccurred.Theslavepostponesthesendofitsblockunt

编辑推荐

  • 名称/格式
  • 评分
  • 下载次数
  • 资料大小
  • 上传时间

用户评论

0/200
    暂无评论
上传我的资料

相关资料

资料评价:

/ 20
所需积分:1 立即下载
返回
顶部
举报
资料
关闭

温馨提示

感谢您对爱问共享资料的支持,精彩活动将尽快为您呈现,敬请期待!