Timing Acquisition for Distributed Antenna Systems by Exploiting the Advantages of Cooperation

合集下载

北斗定位-毕业论文外文文献翻译

外文文献原稿和译文原稿Beidou positioningPrefaceNavigation satellite systems can provide all time, all weather and high accuracy positioning, navigation and timing services to users on the earth surface or in the near-earth space. It is an important space inf rastructure, which extends people’s range of activities and promotes social development. Satellite navigation is bringing up revolutionary changes to the world politics, economy, military, technology and culture.With a long history and a splendid culture, China is one of the important cradles of early human civilization. In ancient times, Chinese people used the Big Dipper (Beidou) for identifying directions, and invented the world’s first navigation device, the ancient compass (Sinan), which was a great contribution to the development of world civilization. In modern society, the Chinese-built BeiDou（COMPASS） system will become another contribution to the mankind.In early 1980s, China began to actively study the navigation satellite systems in line with C hina’s conditions. In 2000, BeiDou Navigation Demonstration System is basically established, which made China the third nation in possession of an independent navigation satellite system following the United States and Russia. At present, China is steadily accelerating the construction of the BeiDou Navigation Satellite System, and has already successfully launched 10 satellites so far.The BeiDou system will meet the demands of China’s national security, economic development, technological advances and social progress, safeguard national interests and enhance the comprehensive national strength. The BeiDou system will commit to providing stable, reliable and quality satellite navigation services for global users. Along with other GNSS providers, the BeiDou system will jointly promote the development of satellitenavigation industry, make contributions to human civilization and social development, serve the world and benefit the mankind.I. System DescriptionThe BeiDou system is comprised of three major components: space constellation, ground control segment and user terminals. The space constellation consists of five GEO satellites and 30 non-GEO satellites. The GEO satellites are positioned at 58.75°E, 80°E, 110.5°E, 140°E and 160°E respectively. The non-GEO satellites include 27 MEO satellites and three IGSO satellites. The MEO satellites are operating in an orbit with an altitudeof 21,500 km and an inclination of 55°, which are evenly distributed in three orbital planes. The IGSO satellites are operating in an orbit with an altitude of 36,000 km and an inclination of 55°, which are evenly distributed in three inclined geo-synchronous orbital planes. The subsatellite track for the three IGSO satellites are coincided while the longitude of the intersection point is at 118°E, with a phase difference of 120°.Ground control segment consists of several Master Control Stations (MCS), Upload Stations (US) and a network of globally distributed Monitor Stations (MS). The main tasks of MCS are to collect observing data from each MS, to process data, to generate satellite navigation messages, wide area differential data and integrity information, to perform mission planning and scheduling, and to conduct system operation and control. The main tasks of Upload Stations include completing the upload of satellite navigation messages, wide area differential data and integrity information, controlling and managing the payload. The tasks of Monitor Stations include continuous tracking and monitoring of navigation satellites, receiving navigation signals, sending observational data to the Master Control Station for the satellites orbit determination and time synchronization.The user terminals include various BeiDou user terminals, and terminals compatible with other navigation satellite systems, to meet different application requirements from different fields and industries.The time reference for the BeiDou Navigation Satellite System uses BeiDou Time (BDT). BDT’s length of second is a SI second. BDT was zero at 0:00:00 on Janu ary 1, 2006 Coordinated Universal Time (UTC). BDT is a continuous system, traceable to the UTC time maintained by the National Time Service Center (NTSC) of ChineseAcademy ofSciences, which is referred to as UTC (NTSC). The leap seconds with UTC information is broadcasted in the navigation messages. The difference between BDT and UTC maintains within 100ns.The coordinate framework of BeiDou system adopts China Geodetic Coordinate System 2000 (CGCS2000).Upon the full system completion, the BeiDou Navigation Satellite System can provide positioning, navigation and timing services to worldwide users. It can also provide wide area differential services with the accuracy of 1m and short messages services with the capacity of 120 Chinese characters each time.·Main functions: positioning, velocity measurement, one-way and two-way timing, short messages·Service area: global·Positioning accuracy: better than 10m·Velocity accuracy: better than 0.2m/s·Timing accuracy: 20nsII. System DevelopmentThe BeiDou system has followed the development concept of starting with regional services first and expanding to global services later. A three-step development strategy has been taken, with specifics as follows:Phase I: BeiDou Navigation Satellite Demonstration System. In 1994, Chinastarted the construction of BeiDou Navigation Satellite Demonstration System. In 2000, two BeiDou navigation experiment satellites were launched, and the BeiDou Navigation Satellite Demonstration System was basically established. In 2003, the third BeiDou navigation experiment satellite was launched, further enhancing the performance of the BeiDou Navigation Satellite Demonstration System.BeiDou Navigation Satellite Demonstration System consists of three major components: space constellation, ground control segment and user terminals. The space constellation includes three geostationary orbit (GEO) satellites, positioned at longitude of 80 degrees East, 110.5 degrees East and 140 degrees East respectively above the equator. Ground control segment consists of the ground control center and a number of calibrationstations. The ground control center is to complete satellite orbit determination, ionospheric correction, user location determination and user short message information exchange and processing. The calibration ground control stations are mainly to provide the distance measurement and correction parameters to the ground control center.The user terminals include the hand-held type, vehicle type, command type and other types of terminals, capable of position service application, location coordinates information receiving and other functions.The main functions and performance specifications of the BeiDou Navigation Satellite Demonstration System are as follows:·Main functions: positioning, one-way and two-way timing, short message communications;·Service Area: China and the surrounding areas;·Positioning Accuracy: better than 20 meters;·Timing Accuracy: 100 ns one-way, two-way 20 ns;·Short message communications: 120 Chinese characters per time.Phase II: BeiDou Navigation Satellite (regional) System. In 2004, Chinastarted construction of BeiDou Navigation Satellite System. In 2007, the first satellite, a round medium earth orbit satellite (COMPASS-M1) was launched. By 2012, the BeiDou system will consist of 14 satellites, including five GEO satellites, five IGSO satellites (two in-orbit spares), and four MEO satellites.The functions and performance parameters of BeiDou Navigation Satellite (regional) System are as follows:·Main functions: positioning, velocity measurement, one-way and two-way timing, short message communications;·Service Area: China and part of Asia- Pacific region ;·Positioning Accuracy: better than 10 meters;·Velocity Accuracy: better than 0.2 m/s;·Timing Accuracy: 50 ns;·Short message communications: 120 Chinese characters per message.Phase III: BeiDou Navigation Satellite System will completely be established by 2020.III. System ApplicationsSince it was officially brought into service in 2003, the BeiDou Navigation Satellite Demonstration System has been widely used in transportation, marine fisheries, hydrological monitoring, weather forecasting, forest fire prevention, timing for communication systems, power distribution, disaster mitigation, national security, and many other fields, which has been resulting in significant social and economic benefits. Particularly, the system has played an important role in the South China frozen disaster, earthquake relief in Wenchuan, SichuanProvince and Yushu, Qinghai Province, the Beijing Olympic Games, and the Shanghai World Expo.—In the field of transportation, built on the Beidou Navigation Satellite Demonstration System, applications such as Xinjiang Satellite Navigation Monitoring System of Public Transport, the Highway Infrastructure Safety Monitoring System, and the Port Scheduling High-precision Real-time Position Monitoring System, have promoted the BeiDou system and achieved a good demonstration effect.—In marine fisheries, built on the BeiDou Navigation Satellite Demonstration System, the marine fisheries integrated information service platform has provided vessel position monitoring, emergency rescue, information distribution, fishing boats in and out of port management and other services to the fishery administration departments.—The hydrological monitoring system, based on the BeiDou Navigation Satellite Demonstration System, has realized the real-time transmission of hydrological forecast information in mountainous regions, which has improved the accuracy o f the disaster forecasting and has helped the planning and scheduling programs for the flood and drought control.—In the field of weather forecasting, a series of BeiDou terminal equipment have been developed for weather forecast, and various practical and feasible system solutions have been worked out to address the automatic data transmission issues for the China Meteorological Administration and a number of local weather centers and stations.—In the field of forest fire prevention, the BeiDou Navigation Satellite Demonstration System has been successfully used in forest fire prevention system. Its positioning and short message communication services have achieved good results.—In the field of time synchronization for communication systems, the successful implementation of BeiDou two-way timing demonstration program has achieved breakthroughs in some key technical areas such as long distant fiber technology, and an integrated satellite-based timing system has been developed.—In the field of power distribution, built on the BeiDou Navigation Satellite Demonstration System, the successful implementation of power system time synchronization demonstration program has created basis for the high precision applications such as the electric accident analysis, the electricity early warning and protection systems.—In the field of disaster mitigation, the navigation, positioning, short message communications and position reporting capabilities of the BeiDou Navigation Satellite Demonstration System have provided services for the nationwide real-time disaster relief commanding and dispatching, emergency communications, rapid reporting and sharing of disaster information, which has significantly improved the rapid response of the disaster emergency relief and decision-making capability.Upon the full completion, the BeiDou Navigation Satellite System will provide more high-performance positioning, navigation, timing and short-message communication services for civil aviation, shipping, railways, finance, postal and other industries.IV. International Exchange and CooperationThe international exchange and cooperation for the BeiDou Navigation Satellite System will be carried out in an active and pragmatic way, which is in line withChina’s foreign policies, focusing on China's basic tasks and strategic objectives for the construction of navigation satellite systems, using the domestic and international markets and resources in a coordinated way. The international exchange and cooperation will be proceeded in a phased, focus-centered, non-discriminatory and selective approach in accordance with the overall development plan of China's navigation satellite system. It will be built upon the basis of equality, mutual benefit, mutual complementarity, peaceful utilization and mutual development and the generally accepted principles of the international laws.The BeiDou Navigation Satellite System adheres to the open and friendly attitude, and has already carried out extensive exchanges and consultation with the countries that have navigation satellite systems, to promote navigation satellite system compatibility and interoperability globally. Through the exchange and cooperation with countries that do not have a navigation satellite system, we also support their use of the existing resources globally and share the benefits of the satellite navigation development.China's international exchange and cooperation in the field of satellite navigation started in the 1990s. In nearly 20 years, various forms of activities have been carried out with extensive results.In 1994, under the framework of International Telecommunication Union(ITU),China started the BeiDou Navigation Satellite System frequency coordination activities. Satellite network information was submitted in accordance with the BeiDou system construction plan and progress. International frequency coordination has been carried out in a phased, step by step, focus-centered approach. China has actively participated bilateral frequency coordination activities with Europe, the UnitedStates and Russia, and has actively taken part in the World Radiocommunication Conference and the meetings of ITU study groups and working groups.China, as an important member of the International Committee on Global Navigation Satellite Systems (ICG), has participated in every ICG General Assembly Meeting and the ICG Providers Forum. In 2007, China became one of the four core providers designated by the organization. Focusing on compatibility and interoperability, China has carried out the extensive exchange and cooperation with the other navigation satellite systems in the world. The Technical Working Group (TWG) on compatibility and interoperability between BeiDou and Galileo was established. Until now, seven TWG meetings have been held.China actively participates, organizes and hosts international academic exchanges on satellite navigation, which include the American Institute of Navigation (ION) Conferences, the International Symposium on GPS/GNSS (ISGNSS), Munich Satellite Navigation Summit and other international conferences and forums. The China academic conferenceon satellite navigation is held annually, together with many other forums and seminars.China encourages and supports domestic research institutions, industrial enterprises, universities and social organizations, under the guidance of the government policy, to carry out international exchanges, coordination and cooperation activities with other countries and international organizations in the fields of the compatibility and interoperability, satellite navigation standards, coordinates frame, time reference, application development and scientific research. China has been actively engaged in international activities in terms of monitoring and assessment of open service for GNSS to promote the BeiDou Navigation Satellite System better serving the global users, and to promote the development of satellite navigation technology.ConclusionThe rapid development of the BeiDou Navigation Satellite System is attributedto China's reform and opening-up policy as well as the sustainable development of economy. As always, China will continue to promote the Global Navigation Satellite System construction and industrial development, to encourage the use of new satellite navigation technologies to provide new services, meeting the growing diversified needs of the people. By actively propelling international exchanges and cooperation, China will realize the compatibility and interoperability between the BeiDou Navigation Satellite System and other navigation satellite systems in the world. China will provide global customers with high performance and highly reliable positioning, navigation and timing services.The Launch Record of BeiDouNavigation Satellites·October 31, 2000, launch of 1st BeiDou navigation experiment satellite.·December 21, 2000, launch of 2nd BeiDou navigation experiment satellite.·May 25, 2003, launch of the 3rd BeiDou navigation experiment satellite.·February 3, 2007, launch of the 4th BeiDou navigation experiment satellite.·April 14, 2007, launch of the 1st BeiDou navigation satellite.·April 15, 2009, launch of the 2nd Beidou navigation satellite.·January 17, 2010, launch of the 3rd BeiDou navigation satellite.·June 2, 2010, launch of the 4th BeiDou navigation satellite.·August 1, 2010, launch of the 5th BeiDou navigation satellite.·November 1, 2010, launch of the 6th BeiDou navigation satellite. ·December 18, 2010, launch of the 7th BeiDou navigation satellite. ·April 10, 2011, launch of the 8th BeiDou navigation satellite. ·July 27, 2011, launch of the 9th BeiDou navigation satellite. ·December 2, 2011, launch of the 10th BeiDou navigation satellite.译文北斗定位前言卫星导航系统可以提供所有的时间，所有天气情况下用户在地球表面或近地空间的高精度定位、导航和授时服务。

关于PLC的中英文对照翻译

原文：PLC Communication using PROFINET: ExperimentalResults and AnalysisAbstractPROFINET is the Industrial Ethernet Standard devised by PROFIBUS International for “Ethernet on the plant ﬂoor”. PROFINET allows to implement a comprehensive communications solution on Ethernet which includes peer-to-peer communication between controllers, distributed I/O, machine safety, motion control and data acquisition. In this paper an analysis is conducted on the peer-to-peer interlocking performance based on PROFINET speciﬁcation. Tests were performed to determine the performance of the peer-to-peer communication mechanism, to evaluate the impact of switches on the system, and to measure the impact of data size on peer-to-peer communication performance. The paper summarizes the test results. 1.IntroductionAlthough a wide variety of networks and ﬁeldbuse s have been used in the manufacturing industry over the past decade [1], the widespread adoption of Ethernet as a de facto standard in other domains (e.g., the internet) has made it an attractive option to consider. The increased network speed and the reduced cost of devices has further heightened interest. The introduction of switched Ethernet has allowed formore deterministic behavior and alleviated many of the concerns about unbounded delays [2, 3, 4]. Ethernet is already being widely used as a diagnostic network in manufacturing systems and is making inroads into the control networking domain [5, 6].However, standard Ethernet (IEEE 802.3) is not a deterministic protocol, and network quality of service cannot be guaranteed. To address this inherent nondeterminism, different “ﬂavors” of Ethernet have been proposed for use in industrial automation. Several of these add layers on top of standard Ethernet or on top of the TCP/IP protocol suite to enable the behavior of Ethernet to be moredeterministic [7]. However, the network solutions may no longer be “Ethernet” other than at the physical layer.Since time delay is an important issue in control systems, there have been a number of projects devoted to analyzing and experimentally testing network performance for use in control systems. It has been shown that the largest component of the time delay in sending messages from one node to another is typically not on the network itself, but rather the application layer that interfaces to the network [8, 9]. Experimental analyses have been carried out to speciﬁcally address the issue of delays in switched Ethernet [10, 4]. However, due to the relatively recent introduction of commercial devices that implement the new industrial Ethernet protocols, there have been only a few published accounts of their actual performance [11, 12].Over the past six months, our group at the University of Michigan has undertaken an industrial Ethernet testing project [13]. The goal of the project was to evaluate the suitability of real-time Ethernet for peer-to-peer communication between PLCs on a factory ﬂoor. The purpose of this paper is to summarize the results of our tests on PROFINET, and discuss our ﬁndings.The outline of the paper is as follows. In Section II, we summarize how PROFINET enables real-time communication over Ethernet. In Section III, we describe the tests that were performed. Section IV presents the results of those tests, and conclusions are given in Section V.2.PROFINET CBA with Real-Time Channel Communication PROFINET distinguishes two views: PROFINET IO for integration of distributed I/O and PROFINET CBA (Component Based Automation) for creation of peer-to-peer communication and interlocking between controllers in modular plants (Figure 1)All other PROFINET applications such as safety, motion control, and HMI (Human Machine Interface) are based on these communication modes. PROFINET communication is scalable in three levels: PROFINET TCP/IP Communication (NRT) enables cycle times as low as 100 ms, PROFINET Real-Time Communication (RT) enables cycle times up to 1-10 ms and Isochronous Real-Time Communication (IRT) enables cycle times up to 1 ms with Jitter less than 1µs.Component based communication is realized through PROFINET CBA which uses selectively the TCP/IP or the Real-Time (RT) channel. Communication for distributed I/O is implemented through PROFINET I/O which uses Real-Time and Isochronous Real-Time (IRT) communication.PROFINET Real-Time Channel The PROFINET Real Time Channel is a cyclic communication path used by individual stations to exchange time critical data at periodic intervals speciﬁed by the programmer. It is based on the IEEE and IEC deﬁnition s [14], which only permit a limited time for execution of Real-Time services within a bus cycle. Real-Time data are handled with higher priority than Non-Real-Time (NRT) data. The tightness of the window depends on the Real-Time characteristics. The Real-Time mechanism is based on Layer 2 of the OSI model and several protocol layers are omitted. Thus the communication overhead associated with preparing data, transferring it and making it available to the overlying application for use are reduced. Using Ethereal it was found that the total overhead associated with Cyclic Real Time communication is 56 bytes.3.Tests PerformedThe following tests were designed to measure the impact of system parameters on peer-to-peer interlocking performance using PROFINET CBA with RTcommunication method. The system parameters include data size and number of switches. The tests are vendor neutral so that any implementation can be conﬁgured to undergo each test. Connection failures or errors are not included in this test plan. To perform tests the following equipment was used: one computer with Matlab and the protocol analyzer Ethereal, SIMATIC iMap and STEP7 as conﬁguration software, ﬁve switches from Hirschmann and two Siemens SIMATIC PLCs (Programmable Logic Controllers). The PLCs were conﬁgured using the factory defaults for processor and communication allocation options. The Hirschmann switches (100Mbps) were conﬁgured for port speed auto negotiation. Due to the fact that PROFINET is based on Unicast communication the Multic ast functionality was not conﬁgured in the switches.3.1 PerformanceMetricsThe performance metrics analyzed are PLC1 Packet Time Interval and Round Trip Time Interval.PLC1 Packet Time Interval is the time between two successive transmittals of packets from PLC1. Ideally, the PLC1 Packet Time Interval is always exactly the same as the conﬁgured update interval in the PLC. However, in practice there is some variability associated with this interval. The experimental results that follow summarize the average (mean value) and the jitter (standard deviation) of the PLC1 packet time interval. These metrics (mean and standard deviation) are important, as they give ameasure of the determinismthat can be obtained for realtime control using PROFINET.Round Trip Time Interval is deﬁned as the Time Interval needed for a packet from PLC1 to reach PLC2, be echoed and come back to PLC1. Consider a test where PLC1 generates data and PLC2 echoes themback to PLC1 through a switch.Figure 2 shows the timing chart for the communication between PLC1 and PLC2 where PLC1 sends messages at T1, T2, T3,. . . and PLC2 echoes at t1, t2, t3,. . . . PLC1 Packet Time Interval should be equal to the conﬁgured update interval on PLC1, and PLC2 Packet Time Interval should be equal to conﬁgured update interval on PLC2. If the echo from PLC2 arrives before T2, then the round trip counter getsincremented and the new value is transmitted from PLC1 at T2. Since the increment of the round trip counter is taken for calculation of the Round Trip Time Interval, in this case it should be equal to the PLC1 Packet Time Interval. Consider the case when t1 shifts relative to T2. Then the echo fromPLC2 is received after T2, and the round trip counter is not incremented in themessage transmitted from PLC1 at T2. Hence, the Round Trip Time Interval becomes twice the PLC1 Packet Time Interval.Figure 2. Timing chartFrom the above observations it is noticed that Round Trip Time interval mean and standard deviation are also important as measures of the degree of synchronization for real-time control using PROFINET.3.2 Test DescriptionsTest1: Benchmark Test1 is the benchmark test. The other tests are compared to Test1. In this test PLC1 generates eight bytes of data and PLC2 echoes it back to PLC1 through a switch. PLC1 uses the last 4 bytes (dint) of the data for a new data received counter. PLC1 increments this counter as discussed in section 3.1.To perform measurements, a PC running Ethereal was connected to the managed switch which connects to the PLCs. All packets going to and from PLC2 and theirrespective timestamps were mirrored onto this port.Test2: Network Switches The objective of Test2 is to evaluate the impact that switches introduce to the system. The number of switches between two PLCs is the test variable. The same variables are measured as in Test1. We will consider the case of three and ﬁve switches between the PLCs.Test3: Size of Data The objective of Test3 is to measure the impact of data size on peer-to-peer communication performance. The test variable is the data size. Measurements are performed as described in Test1. We will consider two cases. In the ﬁrst case 216 bytes of unused data, in the second 440 bytes of unused data.4.Test ResultsIn performing the tests and analyzing the results a data capture of 5000 packets per PLC is considered in order to assess the timing performance. The average and standard deviation values of PLC1 Packet Time Interval and Round Trip Time Interval are measured in milliseconds and rounded off to th ree signiﬁcant digits after the decimal point. All tests are performed with an update time of 8ms which is typical for these applications in the factory. Figures 3, 4 and 5 show the benchmark test results, PLC1 Packet Time Interval, Round Trip Time Interval histogram, and Round Trip Time Interval scattering diagram respectively. We can notice the highly deterministic behavior of the network. Since we are using the PROFINET RT protocol a similar behavior is expected also from the other tests.Figure 3. Test1 PLC1 Packet Time Interval histogram4.1 Network SwitchesTo evaluate the impact that switches introduce to the system, data results from Test1 will be compared to those obtained from Test2. Tables 1 and 2 show that, in the case of three or ﬁve switche s between two PLCs, there are no signiﬁcant changes between the two tests. PLCs Packet Time Interval and Round Trip Time Interval present the same average value and similar standard deviation. Figure 6 shows the histogram of round trip time interval for Test2 which is close to that of Test1 (Figure 4). As expected the switches do not alter the performance metrics. Similar resultswere found in [10].Figure 4. Test1 Round Trip Time Interval histogramFigure 5. Test1 Round Trip Time Interval scattering diagramFigure 6. Test2 Round Trip Time Interval histogram, case with 3 switches4.2 Size of DataBy comparing the results of Test1 and Test3 we will measure the impact of data size on peer-to-peer communication performance. As observed in Tables 1 and 2, PLC1 packet and Round Trip Time Interval average values are the same. In both PLC1 packet and Round Trip Time Intervals there is a decrease of value in standard deviation. Figure 7 shows the Round Trip Time Interval of Test3 with three switches which behaves like Test1 round trip interval (Figure 4). From the results obtained (Tables 1 and 2) we can conclude that data size does not impact Packet and RoundTrip Time Interval.Figure 7. Test3 Round Trip Time Interval histogram, case with 216 bytes 5.ConclusionsTo measure the impact of data size carried by a packet and switches on a PROFINET CBA with RT communication based network three tests were designed. Test1, represented by a simple network made of two PLCs and one switch, was used as benchmark. Figures 3, 4 and 5 showed the deterministic behavior of the network. Test2 is similar to Test1 but instead of one switch, three to ﬁve have been used. Test3 is also similar to Test1 but, instead of using 8 bytes data per packet, 216 and 440 bytes were used. To investigate the delay introduced by the switches Test1 and Test2 results were compared. The impact of data size was analyzed by comparing Test1 and Test3. Results show that PLC1 Packet Time Interval and Round Trip Time Interval are unaffected by data size per packet and number of switches. AcknowledgementsThis work was supported in part by the Engineering Research Center for Reconﬁgurable Manufacturing Systems of the National Science Foundation under Award Number EEC-9529125. The authors would also like to acknowledge the support received from General Motors Powertrain, Siemens and Hirschmann in thecompletion of the tests.References[1] J.-P. Thomesse, “Fieldbus Technology in Industrial Automation”, Proc. of theIEEE, vol. 93, no. 6, 2005.[2] J. M oyne and F. Lian, “Design considerations for a sensor bus system insemiconductor manufacturing”, in International SEMATECH AEC/APC Workshop XII, 2000.[3] P. G. Otanez, J. T. Parrott, J. R.Moyne, and D. M. Tilbury, “The Implications ofEthernet as a Co ntrol Network”, in Proc. of the Global Powertrain Congress, 2002.[4] K. C. Lee and S. Lee, “Performance evaluation of switched Ethernet fornetworked control systems”, in Proc. of IEEE Conf. of the Industrial Electronics Society, volume 4, 2002.[5] J.-D. Decotignie, “Ethernet-Based Real-Time and Industrial Communications”,Proc. of the IEEE, vol. 93, no. 6, 2005.[6] J. Montague, “Networks Busting Out All Over”, Control Engineering, vol. 52, no.3, March 2005.[7] M. Felser, “Real-Time Ethernet—Indus try Prospective”, Proc. of the IEEE, vol. 93,no. 6, 2005.[8] F.-L. Lian, J. R. Moyne, and D. M. Tilbury, “Network Design Consideration forDistributed Control Systems”, IEEE Trans. on Control Systems Technology, vol.10, no. 2, 2002.[9] J. T. Parrott, J. R. Moyne, and D. M. Tilbury, “Experimental Determination ofNetwork Quality of Service in Ethernet: UDP, OPC, and VPN”, in Proc. of the American Control Conf., 2006.[10] E. V onnahme, S. Ruping, and U. Ruckert, “Measurements in switched Ethernetne tworks used for automation systems”, in Proc. of IEEE International Workshop on Factory Communication Systems, 2000.[11] P. Ferrari, A. Flammini, and S. Vitturi, “Response Times Evaluation ofPROFINETNetworks”, in Proc. of the IEEE Int. Symposium on IndustrialElectronics, 2005.[12] P. Ferrari, A. Flammini, D.Marioli, and A. Taroni, “Experimental evaluation ofPROFINET performance”, in Proc.of the IEEE Int.Workshop on Factory Communication Systems (WFCS), 2004.[13] K. Acton, S. Mantri, J. Parrott, N. Kalappa, M. Antolovic, J. Luntz, J. Moyne,and D. Tilbury, “UM-ERC Industrial Ethernet Evaluation Project: Peer-to-peer Interlockign Performance Report”, Technical report, University of Michigan Engineering Research Center for Reconﬁgurable Manufactu ring Systems, February 2006.[14] M. Popp, K. Weber, “The Rapid Way to PROFINET”,Editor PROFIBUSNutzeroranisation e.V., 2004.译文：PROFINET在PLC通讯中的使用：实验结果及分析摘要：PROFINET是国际现场总线在“以太网物理层”分离出来的工业以太网标准。

Later Can Be Better Increasing Concurrency of Distributed Transactions

Later Can Be BetterIncreasing Concurrency of Distributed TransactionsWeihai YuDepartment of Computer ScienceUniversity of TromsøNorwayweihai@cs.uit.noAbstractDistributed transactions have poor scalability, both in terms of the amountof concurrent transactions, and the number of sites a distributed transactionmay involve. One of the major factors that limit distributed transactionscalability is that every site that a transaction involves has to hold dataresources until the termination of the entire transaction, i.e., every sub-transaction’s lifetime of resource consumption is bounded to the slowestsub-transaction. There are several solutions to this problem. The basic ideaof these solutions is to release data resources as early as possible before thetermination of the entire distributed transaction. These solutions eithersuffer from cascading aborts or require knowledge of application businessdetails such as the use of compensation. In this paper, we present a totallydifferent approach that delays altruistically the execution of fast sub-transactions. We will show that this approach increases concurrency of theentire distributed system without sacrificing transaction response time.Furthermore, this approach assumes no more than strict two-phase lockingand requires very little knowledge of specific application business process.1 IntroductionDistributed transactions are essential for large-scale distributed applications like e-commerce, enterprise applications, and so on. However, distributed transactions are limited by their scalability, mainly due to sharing of data resources. When a transaction is updating a piece of data, other transactions are excluded from accessing the same data. Typically, the exclusion of access will last until the updating transaction terminates. In fact, nearly all commercial transaction processing systems and transaction processing standards use strict two-phase locking [8][11][15], i.e., locks acquired by a transaction are held until its termination. When transactions get long or involve many sites, they tend to hold data resources exclusively for long duration.However, holding data resources such long may be unnecessary. A lot of research has focused on how data updated by a transaction can be released early such that other transactions will not be unnecessarily blocked (many examples can be found in [6]). Releasing resources early, however, is not without problems. One difficult problem is that a transaction that releases its updated data might be aborted later. Concurrency control mechanisms that allow (somewhat) early release of data resources, like non-strict two-phase locking [3] and altruistic locking [13], suffer from the problem of cascading aborts. Moreover, non-strict two-phase locking requires notification of thestart of the shrinking phase, and is thus not particularly suitable in a distributed environment. Another commonly applied approach to remedy the inconsistency due to early release is the use of compensation [7]. Compensation is not a silver bullet, either. Some operations cannot be compensated. Even when all operations can be compensated, applications must provide compensation transactions, making the development of the application more complicated.We present a totally different approach to reducing blocking without incurring the problem of early release of data resources. More specifically, our approach • reduces unnecessary resource holding, and therefore increases systemconcurrency,• does not release data resources before transaction termination, and therefore does not lead to cascading aborts and does not require compensation, • ensures transaction response time at least as good as with strict two-phase locking, and• is likely to be supported by middleware without application involvement.This paper is organized as follows. Section 2 presents the intuition behind our approach. The key idea is to delay altruistically the execution of fast sub-transactions such that no sub-transaction finishes local processing unnecessarily earlier than other sub-transactions. Section 3 presents the execution model of distributed transactions for further discussions. Section 4 discusses how altruistic delays can be determined in the transaction execution model. Section 5 argues that altruistic delays can also be determined in a generalized transaction execution model. Section 6 discusses how to control altruistic delays in practice. Section 7 presents our plan for future research. Section 8 discusses some related work. Finally Section 9 summarizes the contributions of this work.2 Approach OverviewFigure 1 illustrates the timing of a typical execution of a transaction distributed at processes 1, 2, 3 and 4 as sub-transactions. The execution of each sub-transaction consists of the following stages:1. Start of the sub-transaction. A request is delivered to the process on behalf of thetransaction. The necessary initiation and enlistment is done at this stage.2. Acquisition of data resources. Locks are acquired on the data the sub-transactionis going to access.3. Data processing. The data on which the sub-transaction has acquired locks areread and updated.4. Unnecessary holding of data resources. After processing the data, the sub-transaction has to hold the locks until the termination of the transaction, i.e., until it is notified of the outcome of the transaction.5. Release of data resources. Finally the locks are released upon termination of thetransaction.As mentioned in the introduction, one major factor that limits the scalability of distributed transactions is stage 4 above. That is, sub-transactions have to hold data resources unnecessary after having accessed them. The duration of this unnecessaryholding can be long and is generally not decidable locally at the sites of the sub-transactions.In our approach, we introduce altruistic delays to the executions of sub-transactions. A sub-transaction acquires locks on data resources only after the altruistic delay. Ideally, by executing local data processing after the altruistic delays, the sub-transactions do not hold data resources unnecessarily (Figure 2). In practice, however, it is impossible to totally eliminate unnecessary holding of data resources. Our goal is therefore to minimize, or at least significantly reduce, unnecessary holding of data resources.issue in three steps:• We start with a primitive transaction execution model where the necessary timing of transaction invocation and execution is known. This execution modelis defined in Section 3. We will show in Section 4 that in this model altruistic delays of sub-transactions can be determined locally at their parent nodes.• Next, we will show in Section 5 that the result in the primitive transaction execution model applies also to a generalized execution model where the necessary timing is still known.• Our ultimate goal is to improve performance of distributed transaction processing in practice where the timing is generally unknown in advance. This will be our future work. In Section 6, we will discuss some possible approaches to achieving this goal.3 An execution model of distributed transactionsWe model execution of distributed transactions in a multi-tier client-server architecture, which typically consists of a presentation tier, a business process tier, a data access tier and a database tier. A transaction is typically started at a process of some tier, say near or at the presentation tier. A transaction at a process may invoke one or more sub-transactions at other processes, possibly at the next tier. Here a process is loosely defined as an address space. The only way for processes to share information is via message sending. Processes may run on different machines. The invocations of sub-transactions form a tree (transaction invocation tree). In the tree, the nodes are sub-transactions at different processes; an invoking process is the parent of the invoked processes; the root is the process where the transaction is started. A distributed transaction is terminated via an atomic commitment protocol, the most widely used of which is the two-phase commitment protocol. In an atomic commitment protocol, a process is also called a participant. Usually, the root of the transaction invocation tree is also the coordinator of the commitment protocol, and the voting and the decision notifications (commit or abort) are communicated between the participants and the coordinator through the invocation tree.The execution of a distributed transaction T is modeled as a tree:T = (N, E, exec, inv, res), where• N = {0, 1, 2, …, n} is the set of nodes and 0 is the root,• E⊆N×N is the set of edges,• exec: N→ Reals, is the time needed to execute sub-transactions locally at nodes,• inv: E→ Reals, is the time needed to invoke sub-transactions, and• res: E→ Reals, is the time needed to send replies.Figure 3 illustrates a transaction as a tree. Every node of the tree is a sub-transaction at a process. Suppose there is no re-entrant invocation at the same process by the same transaction. Thus node i denotes both process i and the sub-transaction at the process. Assume also that there is no message other than those for requests, replies and atomic commitment processing, so executions at different nodes are not synchronized beyond these. An edge from parent node i to child node j indicates an invocation from process i to process j. exec(i) is the time needed to execute sub-transaction locally at process i. inv(i, j) is the time needed to invoke from process i to process j. res(i, j) is the corresponding reply from j to i. Note usually inv(i, j) ≠res(i, j), because the management operations associated with invocations and replies are quite different.Associated with invocations are operations like authentication, authorization, transaction enlistment, initiation, etc., whereas with replies (implicit yes-votes, explained shortly in this sub-section), force-writing of prepare log records etc..For an intermediate node i , the local sub-transaction is executed in parallel with the child sub-transactions. Note that this does not exclude the cases where the local sub-transaction is executed before or after the child sub-transactions. In those case, the local execution time is included in inv (p ,i ) (the before case) or res (p ,i ) (the after case) where p is the parent of i , and exec (i ) is simply 0.The “non re-entrant invocation” assumption is not unrealistic. After all, distributed applications should be designed to avoid a component invocating the same remote component multiple times (see for example [2]). An exception can occur at the data access tier where a component invokes a database multiple times in the same transaction via the same database connection (stored procedures are a way of avoiding multiple invocations of this kind). In this case, we can model the entire data access tier as a single node and our non re-entrance assumption still holds. In Section 5, we will see that even the non re-entrance assumption is not necessary.In our transaction execution model, we assume strict two-phase locking and the two-phase commitment protocol [3], which are used in nearly all transaction processing products and standards. The root of the transaction tree is the coordinator of the two-phase commitment protocol. We assume the implicit yes-vote optimization of the two-phase commitment protocol [14], because it can be applied more directly in the subsequent discussions. A leaf node generates an implicit yes-vote right after its execution of all the local operations of the transaction. Note in our model there is no re-entrant invocation to the same process. In general, however, the last successful return from the requests of the same transaction is regarded as an implicit yes-vote. A non-leaf node generates an implicit yes-vote when it has received implicit yes-votes from all its children and when it has finished its local execution. So the implicit yes-votes are propagated from the child nodes to their parents and recursively upward to the root.Figure 3. Distributed transaction as a tree 0 exec (0)res (0,2) 1 exec (1)3 exec (3)4 exec (4)5 exec (5)6 exec (6)7 exec (7)8 exec (8) 2 exec (2) inv (1,3)inv (1,4) inv (0,1)inv (0,2) inv (2,5) inv (5,7) inv (5,6)inv (6,8)res (0,1)res (1,3)res (1,4) res (2,5) res (5,7) res (5,6)res (6,8)Ideally, every implicit yes-vote should arrive at the root at the same time, so no node is unnecessarily holding data resources while the root is waiting for the implicit yes-vote yet to be generated or delivered from some other node.4 Determining altruistic delaysFirst, we define the height h i of node i as the time interval between the process i receives a request and it is ready to reply with an implicit yes-vote:h i = max (exec(i), max(j is a child of i) (inv(i, j) + h j + res(i, j)))That is, after receiving the request, it concurrently starts local execution and sends requests to all subsequent processes. It is ready for replying with implicit yes-vote when it finishes local execution and receives implicit yes-votes from all child sub-transactions.Ideally for every non-leaf node, i, the implicit yes-votes from all its children arrive exactly at the moment the local execution finishes. The delay d(j) of its child j and delay of its own local execution d_local(i) can be assigned such thatinv(i, j) + d(j) + h j + res(i, j) = d_local(i) + exec(i) = h iNote that the altruistic delay at node, i, consists of two parts:• d(i), delay all activities, including local execution and invocations to the children, and• d_local(i), delay of local execution in addition to d(i).Now the altruistic delays of all nodes can be obtained, starting from the root.main(){d[0] ß 0;assign_delay_for_children(0);}assign_delay_for_children(i){d_local[i] = h i – exec[i];if “there is no child”return;for every child j{d[j] ß h i – (inv[i,j] + h j + res[i,j]);assign_delay_for_children(j);}}Figure 4 shows the executions of the distributed transaction in Figure 3, with and without altruistic delays, given some hypothetical values of inv(), exec(), and res(). Notice that no altruistic delay is introduces at node 8, due to the slowest path 0à2à5à6à8. At all other nodes (with the exception of node 2), the time lengths for resource blocking are significantly reduced with the introduction of altruistic delays. At node 2, exec(2) is 0, whereas inv(1,2) is quite long, a case in which local sub-transactionis executed before the child sub-transactions. Like at other nodes, at node 2, locks acquired during local execution must be held until the termination of the entire distributed transaction.5 Generalization of the execution modelOur transaction execution model presented in Section 3 can be generalized. In the generalized model, a node can be re-entrant and the execution of some children may be dependent on the execution of some other children of the same parent.In Figure 5, execution of a consists of a 1, a 2, a 3 and a 4. Execution of b is independent of its parent a and other children of a . Execution of c is dependent on a 1. Execution of d is dependent on both a 2 (which is dependent on c ) and sibling c . a is re-entrant with a 3 executing the invocation from d . Finally, the execution a 4 is dependent on the execution of d .1342568713425687Figure 4. Executions with and without altruistic delaysFigure 5. Node in the generalized execution modelExecution dependencies among child transactions introduce some complexity in determining the altruistic delays. For example, delaying at c will postpone the execution of d, which will incur even more unnecessary delay of the entire transaction. One way to model this is to regard the entire A = (a1àcàa2àd1àa3àd2àa4) as a single sequential execution in parallel with b. Altruistic delays of b and A are thus decidable at a using the algorithm in Section 4.In essence, altruistic delays should only be considered at the forks of concurrent execution branches. Sequential executions, albeit distributed over different nodes, will not benefit from the introduction of altruistic delays.6 Controlling altruistic delays in practiceIn reality, local execution time and message delays are non-deterministic and unknown in advance. Non-determinism is a combined effect of factors like workload variation, race conditions, run-time resource scheduling, network protocol queue lengths, paging, caching, query spaces, program branching, etc. Controlling any of these factors is a major issue of research in areas like QoS management.We propose here two possible approaches to control altruistic delays in practice: • Control based on static analysis. Here timing of different components is obtained based on a white-box analysis of the application. This approach is particularly suitable for tuning benchmarks or applications whose business process structure is pretty static.• Control based on dynamic analysis. Here altruistic delays are dynamically determined based on analysis on statistics of previous executions of transactions.This can be done either by the application or by the middleware.Next, we briefly discuss these different approaches.6.1 Control based on static analysisIn this approach, the application execution without altruistic delay is first profiled. Profiling at components that create concurrent sub-transactions is particularly important, because as shown in Section 4, altruistic delays can be determined locally at parent nodes. If the differences of response time of sub-transactions are stable and considerable, the slowest sub-transaction is the basis for determining the altruistic delays of the other sibling sub-transactions. Care must be taken of whether the slowest sub-transaction is dependent on some other sibling sub-transaction (as in the generalized execution model).6.2 Control based on dynamic analysisThis approach can be implemented either directly by the application or by the supporting middleware.Implementation by the application is similar to the approach based on static analysis. Statistics on response time is taken at components that create concurrent sub-transactions. Again, if the differences of response time of sub-transactions are stable and considerable, executions of sub-transactions are aligned with the slowest sub-transaction.Ultimately, control of altruistic delays should be supported by middleware, whose main task is to support large-scale distributed applications.Basically, analysis can be done by interceptors on a per remote invocation basis. In transactional component middleware such as EJB and COM+, the run-time such as a container intercepts every incoming and outgoing request.For example, the middleware run-time records in the thread-specific transaction contexts (such as the context objects in COM+) the timestamp of the sending of every request and the reception of every reply. In this way, the recording is thread-specific and need not be synchronized with other threads. The recorded data is flushed to a shared data structure during component life-cycle operations (such as returning to object pool, deactivation etc.). A low-priority thread periodically reads the shared data structure and adjusts altruistic delays using certain forecasting methods.One of the difficulties with middleware support is the lack of knowledge of the structure of application business process. Particularly useful is the knowledge of execution dependencies. Hopefully, detailed statistic analysis will uncover the dependencies. For example, a clear indication of some dependency between two child sub-transactions of the same parent is that a request message to one child is always sent after the parent receives a reply from the other child. This is one of the issues we will work on in the future.7 Future WorkWe are now evaluating the benefits of our approach with static analysis of some typical distributed applications.Our ultimate goal is middleware support for altruistic delays of distributed transactions in large-scale applications. This work is part of the Arctic Beans project [1]. The primary aim of Arctic Beans is to provide a more open and flexible enterprise component technology, with intrinsic support for configurability, re-configurability and evolution, based on the principle of reflection [4]. Enterprise components arecomponents at server sites running within so called containers which provide support for complicated mechanisms like resource management (threads, memory, sessions etc.), security and transactions. The project focuses on the security and transaction services and how to adapt these services according to the application needs and its environment. We believe a container is the right place to support control of altruistic delays.We will also study if altruistic delays can be applied in adaptive applications. For example, if one sub-transaction is often dominantly long, due to weak connections or even occasional disconnections, executions of other sub-transactions should be aligned with this long sub-transaction.8 Related WorkMost researches that aim at reducing unnecessary resource holding is based on early release of data resources. The key problem is to maintain database consistency when the transaction that has already released some of its updates finally aborts.With non-strict two-phase locking, locks can be released during the shrinking phase [3]. Altruistic locking allows even earlier release of locks if more knowledge of the data access patterns is available [13]. Serializability of transaction executions is ensured. The well-known problem with these approaches is cascading aborts, which can be even more costly to deal with than unnecessary resource holding, particularly in large-scale systems. They are generally unsuitable for distributed transactions because of the extra notification, such as of the termination of the expanding phase, required among involved sites. Moreover, independence of data accesses among different sites is not fully explored.With the use of compensation [7], the early released effects of a transaction can be logically undone if the transaction finally aborts. One problem with this approach is that not every operation is compensatable. Some compensatable operations still have some effects on end-users, such as charge of cancellation (of reservations) fee. In general, implementing a compensation transaction for every (sub-) transaction is not an easy task.With dynamic re-structuring [9], a long transaction can be split into multiple smaller ones. Some of them can commit early. There may or may not be cascading aborts, depending on the dependencies among the new split transactions. Again, detailed knowledge of application business process is required.Both compensation and dynamic re-structuring can be used to deal with transactions with long sequential executions, whereas our approach cannot. All these methods can be used jointly in particular applications.We use the implicit yes-vote optimization [14] of the two-phase commitment protocol to reason about our approach. There are several improvements to the implicit yes-vote optimization (some of them can be found in [5]). One noticeable improvement is called the dynamic two-phase commitment protocol (D2PC) [12]. Actually, D2PC is not limited to implicit yes-votes, though the gain of D2PC in implicit yes-votes is more significant because of the difference in time yes-votes are generated. The basic idea is that propagation of yes-votes does not stop at the root of the tree while some slow sub-transaction is still busy processing. The propagation will go on toward the slowest node (which will become the new coordinator). With D2PC, the total response time is improved, therefore also entire system concurrency. While D2PC focuses on“smoothing out” the effect of the slowest sub-transaction during commitment processing, we consider the combined effect of execution and message delays. With D2PC, when one sub-transaction is considerably longer than the others (say all other yes-votes have already “piled up” at this slowest node), the others still have to hold data resources unnecessarily (possibly considerably long). There is also an additional cost associated with transfer of coordinator in D2PC. It would be interesting to compare quantitatively the D2PC with our approach.As a final remark, the problem our work seeks to address is different from that of scheduling workflow tasks on a set of resources (such as the job-shop scheduling [9]), where the set of workflows with (more complex) inter-task dependencies is known in advance. The goal with task scheduling is either to minimize total execution time of workflows or to meet deadlines of workflows. In our work, although the inter-transaction dependencies could be simple, the total set of transactions is not known in advance. Nor is our goal to meet deadlines or to minimize total execution time.9 ConclusionOne major factor that limits the scalability of distributed transactions is that all sub-transactions have to hold data resources until the slowest sub-transaction finishes. Holding of data resources this long can be unnecessary, because some sub-transaction may have already finished processing its local data. In contrast with the approaches that release data resources before the termination of the entire distributed transaction, we introduce altruistic delays to the executions of sub-transactions. We show in transaction execution models where the necessary timing is known in advance, with the introduction of proper altruistic delays, no sub-transaction holds data resources unnecessarily after local processing. Furthermore, we show some nice properties of our approach: concurrency of the system is enhanced without sacrificing transaction response time; altruistic delays can be determined locally at parent sub-transactions. We also discussed how altruistic delays could be controlled in practice. It seems that altruistic delays can be supported by middleware without specific knowledge about application business structure. How this can be realized will be part of our future research work.10 References[1] Anders A., G. S. Blair, V. Goebel, R. Karlsen, T. Stabell-Kulø and W. Yu, “Arctic Beans:Configurable and Reconfigurable Enterprise Component Architectures”, Middleware 2001 Work-in-Progress paper, IEEE Distributed Systems Online, 2(7), On-line at: /0107/features/and0107.htm, 2001.[2] Alur, D., J. Crupi and D. Malks, Core J2EE Patterns, Best Practice and DesignStrategies, Upper Saddle River, NJ: Printice Hall PTR, 2001.[3] Bernstein, P. A., V. Hadzilacos and N. Goodman, Concurrency Control andRecovery in Database Systems, Reading, MA: Addison-Wesley, 1987.[4] Blair, G., G. Coulson, P. Robin and M. Papathomas, “An Architecture for NextGeneration Middleware”, In Proceedings of Middleware '98, 1998.[5] Chrysanthis, P. K., G. Samaras and Y. J. Al-Houmaily, “Recovery and Performanceof Atomic Commit Processing in Distributed Database Systems”, In Kumar V. and M. Hsu (Eds.), Recovery Mechanisms in Database Systems. Upper Saddle River, NJ: Printice Hall, pp. 370-416, 1998.[6] Elmagarmid, A. (ed.), Database Transaction Models for Advanced Applications,Morgan Kaufman Publishers, 1992.[7] Garcia-Molina, H. and K. Salem, “SAGAS”, In Proceedings of the ACM SIGMODInternational Conference on Management of Data, 1987.[8] Gray, J. and A. Reuter, Transaction Processing: Concepts and Techniques, MorganKaufman Publishers, 1993.[9] Jain, A. S., and S. Meeran “Deterministic Job Shop Scheduling: Past, Present,Future”, European Journal of Operation Research, Elsevier Science, Vol 113, pp 390-434, 1999.[10] Kaiser, G. E., C. Pu, “Dynamic Restructuring of Transactions”, In [6], pp. 265-295,1992.[11] Object Management Group, CORBA Services Specification, Chapter 10,Transaction Service Specification, December, 1998.[12] Raz, Y., “The Dynamic Two Phase Commitment (D2PC) Protocol”, In Gottlob G.and M. Y. Vardi (Eds.), Proceedings of 5th International Conference on Database Theory, LNCS 893, Springer, 1995[13] Salem, K., H. Garcia-Molina and J. Shands, “Altruistic Locking”, ACMTransactions on Database Systems, 19(1), pp. 117-165, 1994.[14] Stonebraker, M., “Concurrency Control and Consistency of Multiple Copies ofData in Distributed INGRES”, IEEE Transactions on Software Engineering, 5(3), pp 188-194, 1979.[15] X/Open Company Ltd., Distributed Transaction Processing: The XA Specification.Document number XO/CAE/91/300, 1991.。

美国伦布科技 Agilent 16800 Series Portable Logic Analyze

Agilent 16800 SeriesPortable Logic AnalyzersData SheetQuickly debug, validate,and optimize your digitalsystem – at a price thatfits your budget.Features and benefits•250 ps resolution (4 GHz) timingzoom to find elusive timing problemsquickly, without double probing•15” display, with available touchscreen, allows you to see more dataand navigate quicklymeasurements and displays of yourlogic analyzer and oscilloscope datalet you effectively track downproblems across the analog anddigital portions of your design•Eight models with34/68/102/136/204 channels,up to 32M memory depth andmodels with a pattern generatorprovide the measurement flexibilityfor any budget•Application support for every aspectof today’s complex designs – FPGAdynamic probe, digital VSA (vectorsignal analysis) and broad processorand bus support2Selection Guide for 16800 Series Portable Logic AnalyzersModels with a built-in pattern generator give you more measurement flexibility1Pattern generator available with 16821A, 16822A and 16823A.Choose from eight models to get the measurement capability for your specific applicationProbes are ordered separately. Please specify probes when ordering to ensure the correct connection between your logic analyzer, pattern generator, and the device under test.Agilent 16800 Series portable logic analyzers offer the performance, applications, and usability your digital development team needs to quickly debug, validate, and optimize your digital system – at a price that fits your budget.The logic analyzer’s timing and state acquisition gives you the power to:•Accurately measure precise timing relationships using4GHz (250ps) timing zoomwith 64K depth•Find anomalies separated in time with memory depthsupgradeable to 32M•Buy what you need today and upgrade in the future. 16800Series logic analyzers comewith independent upgrades for memory depth and state speed •Sample synchronous buses accurately and confidentlyusing eye finder. Eye finderautomatically adjuststhreshold and setup andhold to give you the highestconfidence in measurementson high-speed buses•Track problems from symptom to root cause across severalmeasurement modes byviewing time-correlated datain waveform/chart, listing,inverse assembly, source code, or compare display •Set up triggers quickly andconfidently with intuitive,simple, quick, and advancedtriggering. This capabilitycombines new triggerfunctionality with an intuitiveuser interface•Access the signals that holdthe key to your system’sproblems with the industry’swidest range of probingaccessories with capacitiveloading down to 0.7 pF•Monitor and correlate multiplebuses with split analyzercapability, which providessingle and multi-bus support(timing, state, timing/state orstate/state configurations)Accurately measure precisetiming relationships16800 Series logic analyzers letyou make accurate high-speedtiming measurements with 4GHz(250ps) high-speed timing zoom. Aparallel acquisition architectureprovides high-speed timingmeasurements simultaneouslythrough the same probe used forstate or timing measurements.Timing zoom stays active all thetime with no tradeoffs. View dataat high resolution over longerperiods of time with 64-K-deeptiming zoom.Figure 1. With eight models to choose from, you can get alogic analyzer with measurement capabilities that meetyour needs.3Automate measurement setup and quickly gain diagnostic clues16800 Series logic analyzers make it easy for you to get up and running quickly by automating your measurement setup process. In addition, the logic analyzer’s setup/hold window (or sampling position) and threshold voltage settings are automatically determined so you can capture data on high-speed buses with the highest accuracy. Auto Threshold and Sample Position mode allow you to...•Obtain accurate and reliable measurements•Save time during measurement setup•Gain diagnostic clues and identify problem signalsquickly•Scan all signals and buses simultaneously or just a few•View results as a composite display or as individual signals•See skew between signals and buses•Find and fix inappropriate clock thresholds•Measure data valid windows•Identify signal integrityproblems related to rise times,fall times, data valid windowwidths Identify problem signals overhundreds of channels simultaneouslyAs timing and voltage marginscontinue to shrink, confidencein signal integrity becomes anincreasingly vital requirementin the design validation process.Eye scan lets you acquire signalintegrity information on allthe buses in your design, undera wide variety of operatingconditions, in a matter ofminutes. Identify problem signalsquickly for further investigationwith an oscilloscope. Results canbe viewed for each individualsignal or as a composite ofmultiple signals or buses.Extend the life of your equipmentEasily upgrade your 16800 Serieslogic analyzer. “Turn on”additional memory depth andstate speed when you need more.Purchase the capability youneed now, then upgrade as yourneeds evolve.Figure 2. Identify problem signals quickly by viewing eye diagrams across all buses and signals simultaneously.4578910A Built-in Pattern Generator Gives You Digital Stimulus and Responsein a Single InstrumentSelected 16800 Series models (16821A, 16822A and 16823A)also include a 48-channel pattern generator to drive down risk early in product development. With a pattern generator you can:•Substitute for missing boards,integrated circuits (ICs) or buses instead of waiting for missing pieces •Write software to createinfrequently encountered test conditions and verify that the code works – before complete hardware is available •Generate patterns necessary to put a circuit in a desired state,operate the circuit at full speed or step the circuit through a series of states •Create a circuit initialization sequence Agilent 16800 Series portable logic analyzers with a pattern generator offer a variety offeatures that make it easier for you to create digital stimulus tests.Vectors up to 48 bits wideVectors are defined as a “row” of labeled data values, with each data value from one to 48 bits wide. Each vector is output on the rising edge of the clock.Create stimulus patterns for the widest buses in your system.Depth up to 16 M vectorsWith the pattern generator, you can load and run up to 16Mvectors of stimulus. Depth on this scale is most useful when coupled with powerful stimulus generated by electronic design automation tools, such as SynaptiCAD’sWaveFormer and VeriLogger.These tools create stimulus using a combination of graphicallydrawn signals, timing parameters that constrain edges, clock signals,and timing and Boolean equations for describing complex signal behavior. The stimulus also can be created from design simulation waveforms. The SynaptiCAD tools allow you to convert .VCD files into .PGB files directly, offering you an integrated solution that saves you time.Synchronized clock outputYou can output data synchronized to either an internal or external clock. The external clock is input via a clock pod, and has nominimum frequency (other than a 2ns minimum high time).The internal clock is selectable between 1MHz and 300MHz in 1-MHz steps. A Clock Out signal is available from the clock pod and can be used as an edge strobe with a variable delay of up to 8ns.Initialize (INIT) block for repetitive runsWhen running repetitively, the vectors in the initialize (init)sequence are output only once,while the main sequence isoutput as a continually repeating sequence. This “init” sequence is very useful when the circuit or subsystem needs to be initialized.The repetitive run capability is especially helpful whenoperating the pattern generator independent of the logic analyzer.“Send Arm out to…” coordinates activity with the logic analyzerVerify how your system responds to a specific stimulus sequence by arming the logic analyzer from the pattern generator. A “Send Arm out to…” instruction acts as a trigger arming event for the logic analyzer or other test equipment to begin measurements. Arm setup and trigger setup of the logic analyzer determines the action initiated by “Send Arm out to…”.Figure 3. Models with a built-in pattern generator give you more measurement flexibility.“Wait for External Event…” forinput patternThe clock pod also accepts a 3-bit input pattern. These inputs are level-sensed so that any number of “Wait for External Event”instructions can be inserted into a stimulus program. Up to four pattern conditions can be defined from the OR-ing of the eight possible 3-bit input patterns. A “Wait for External Event” also can be defined to wait for an Arm. This Arm signal can come from the logic analyzer. “Wait for External Event…” allows you to executea specific stimulus sequence only when the defined external event occurs.Simplify creation of stimulus programs with user-defined macros and loops User macros permit you to define a pattern sequence once, then insert the macro by name wherever it is needed. Passing parameters to the macro will allow you to create a more generic macro. For each call to the macro you can specify unique values for the parameters.Loops enable you to repeat a defined block of vectors for a specified number of times. Loops and macros can be nested, except that a macro cannot be nested within another macro. At compile time, loops and macros are expanded in memory to alinear sequence.Convenient data entry andediting featureYou can conveniently enterpatterns in hex, octal, binary,decimal, and signed decimal(two’s complement) bases. Tosimplify data entry, you can viewthe data associated with anindividual label with multipleradixes. Delete, Insert, and Copycommands are provided for easyediting. Fast and convenientPattern Fills give the programmeruseful test patterns with a fewkey strokes. Fixed, Count, Rotate,Toggle, and Random patterns areavailable to help you quicklycreate a test pattern, suchas “walking ones.” Patternparameters, such as step size andrepeat frequency, can be specifiedin the pattern setup.ASCII input file format: your designtool connectionThe pattern generator supportsan ASCII file format to facilitateconnectivity to other tools in yourdesign environment. Because theASCII format does not support theinstructions listed earlier, theycannot be edited into the ASCIIfile. User macros and loops alsoare not supported, so the vectorsneed to be fully expanded in theASCII file. Many design tools willgenerate ASCII files and outputthe vectors in this linear sequence.Data must be in hex format, andeach label must represent a set ofcontiguous output channels.ConfigurationThe pattern generator operateswith the clock pods, data pods,and lead sets described later inthis document. At least one clockpod and one data pod must beselected to configure a functionalsystem. You can select from avariety of pods to provide thesignal source needed for your logicdevices. The data pods, clock podsand data cables use standardconnectors. The electricalcharacteristics of the data cablesare described for users withspecialized applications who wantto avoid the use of a data pod.Direct connection to yourtarget systemYou can connect the patterngenerator pods directly to astandard connector on your targetsystem. Use a 3M brand #2520Series or similar connector. Theclock or data pods will plug rightin. Short, flat cable jumpers canbe used if the clearance aroundthe connector is limited. Use a 3M#3365/20, or equivalent, ribboncable; a 3M #4620 Series orequivalent connector on thepattern generator pod end of thecable, and a 3M #3421 Series orequivalent connector at yourtarget system end of the cable.Probing accessoriesThe probe tips of theAgilent10474A, 10347A, 10498A,and E8142A lead sets plugdirectly into any 0.1-inch gridwith 0.026-inch to 0.033-inchdiameter round pins or 0.025-inchsquare pins. These probe tipswork with the Agilent5090-4356surface mount grabbers andwith the Agilent5959-0288through-hole grabbers, providingcompatibility with industrystandard pins.A Built-in Pattern Generator Gives You Digital Stimulus and Response in a Single Instrument3-STATE IN TTLPattern generator cable pin outsData cable (Pod end)Clock cable (Pod end)2122Unleash the Complementary Power of a Logic Analyzer and an Oscilloscope Seamless scope integrationwith View ScopeEasily make time-correlatedmeasurements between Agilentlogic analyzers and oscilloscopes.The time-correlated logic analyzerand oscilloscope waveforms areintegrated into a single logicanalyzer waveform display foreasy viewing and analysis. Youcan also trigger the oscilloscopefrom the logic analyzer (or viceversa), automatically de-skew thewaveforms and maintain markertracking between the twoinstruments. Perform thefollowing more effectively:•Validate signal integrity•Track down problems caused by signal integrity•Validate correct operation of A/D and D/A converters •Validate correct logical and timing relationships betweenthe analog and digital portions of a designConnectionThe Agilent logic analyzer and oscilloscope can be physically connected with standard BNC and LAN connections. Two BNC cables are connected for cross triggering, and the LAN connection is used to transfer data between the instruments. The View Scope correlation software is standard in the logic analyzer’s application software version 3.50 or higher. The View Scope software includes:•Ability to import some or all of the captured oscilloscopewaveforms•Auto scaling of the scopewaveforms for the best fit inthe logic analyzer displayFigure 4. View Scope seamlessly integrates your scopeand logic analyzer waveforms into a single display.2324Acquisition and analysis tools provide rapid insight into your toughest debug problemsYou have unique measurement and analysis needs. When you want to understand what your target is doing and why, you need acquisition and analysis tools that rapidly consolidate data into displays that provide insight into your system’s behavior.Figure 5. Perform in-depth time, frequency and modulation domain analysis on your digital baseband and IF signals with Agilent’s 89600 Vector Signal Analysis software.Save time analyzing your unique design with a turnkey setup Agilent Technologies and our partners provide an extensive range of bus and processor analysis probes. They provide non-intrusive, full-speed,real-time analysis to accelerate your debugging process.•Save time making bus-and processor-specificmeasurements withapplication specific analysisprobes that quickly andreliably connect to yourdevice under test•Display processor mnemonicsor bus cycle decode•Get support for acomprehensive list ofindustry-standard processorsand buses252627ProgrammabilityYou can write programs to control the logic analyzer application from remote computers on the local area network using COM or ASCII. The COM automation serveris part of the logic analyzer application. This software allows you to write programs to control the logic analyzer. All measurement functionality is controllable via the COM interface.The B4608A Remote ProgrammingInterface (RPI) lets you remotelycontrol a 16800 Series logicanalyzer by issuing ASCIIcommands to the TCP socketon port 6500. This interface isdesigned to be as similar aspossible to the RPI on 16700Series logic analysis systems,so that you can reuse existingprograms.The remote programminginterface works through the COMautomation objects, methods,and properties provided forcontrolling the logic analyzerapplication. RPI commands areimplemented as Visual Basicmodules that execute COMautomation commands, translatetheir results, and return propervalues for the RPI. You can use theB4606A advanced customizationenvironment to customize andadd RPI commands.Figure 6. 16800 Series programming overview2816800 Series Interfaces2930Figure 9. 16800 Series back panelFull profile PCI card expansion slotExternal display portParallel portSerial port10/100 Base T LAN 2.0 USB ports (4)Clock inTrigger out Trigger in Keyboard Mouse AC power Figure 8. 16800 Series front panelOn/Off power switch 15 inch built-in color LCD display, Touch Screen available General purpose knob Run/stop keys Touch screen on/off (if ordered)16800 Series Physical CharacteristicsDimensionsPower 16801A 115/230 V, 48-66 Hz, 605 W max 16802A 115/230 V, 48-66 Hz, 605 W max 16803A 115/230 V, 48-66 Hz, 605 W max 16804A 115/230 V, 48-66 Hz, 775 W max 16806A 115/230 V, 48-66 Hz, 775 W max 16821A 115/230 V, 48-66 Hz, 775 W max 16822A 115/230 V, 48-66 Hz, 775 W max 16823A 115/230 V, 48-66 Hz, 775 W max Weight Max net Max shipping 16801A 12.9 kg 19.7 kg (28.5 lbs)(43.5 lbs)16802A 13.2 kg 19.9 kg (28.9 lbs)(43.9 lbs)16803A 13.7 kg 20.5 kg (30.3 lbs)(45.3 lbs)16804A 14.2 kg 21.0 kg (31.3 lbs)(46.3 lbs)16806A 14.6 kg 21.4 kg (32.1 lbs)(47.1 lbs)16821A 14.2 kg 20.9 kg (31.2 lbs)(46.2 lbs)16822A 14.2 kg 21.1 kg (31.6 lbs)(46.6 lbs)16823A14.5 kg 21.3 kg (32.0 lbs)(47.0 lbs)Instrument operating environment Temperature 0˚ C to 50˚ C (32˚ F to 122˚ F)Altitude To 3000 m (10,000 ft)Humidity8 to 80% relative humidity at 40˚ C (104˚ F)Figure 7. 16800 Series exterior dimensionsFigure 10. 16800 Series side view330.32(13.005)Dimensions: mm (inches)28.822(11.347)443.23(17.450)Agilent 1184A TestmobileThe Agilent 1184A testmobile gives you a convenient means of organizing and transporting your logic analyzer and accessories.The testmobile includes the following:•Drawer for accessories(probes, cables, power cords)•Keyboard tray with adjustable tilt and height•Mouse extension on keyboard tray for either right or lefthand operation•on uneven surfaces••Load limits:Total: 136.4 kg (300.0 lb.)Figure 11. Agilent 1184A testmobile cartFigure 12. Agilent 1184A testmobile cart dimensions3132Stationary shelfThis light-duty fixed shelf isdesigned to support 16800 Series logic analyzers. The shelf can be used in all standard Agilent racks. The stationary shelf is mounted securely into placeusing the supplied hardware and is designed to sit at the bottom of the EIA increment. Features of the stationary shelf include:•Snap-in design for easy installation •Smooth edgesRack accessoriesSliding shelfThe sliding shelf provides a flat surface with full product accessibility. It can be used in all Agilent racks to support 16800Series logic analyzers. The shelf and slides are preassembled for easy installation. Features of the sliding shelf include:•Snap-in design for easy installation •Smooth edgesConsider purchasing the steel ballast (C2790AC) to use with the sliding shelf. The ballast provides anti-tip capability when the shelf is extended.Figure 15. Sliding shelf (J1526AC)Figure 14. Stationary shelf (J1520AC)Figure 13. Sliding shelf installed in rackEach 16800 Series portable logicanalyzer comes with one PS/2keyboard, one PS/2 mouse,accessory pouch, power cord and1-year warranty standard.Selecting a logic analyzer to meet your application and budget is as easy as 1, 2, 3333435。

synopsys iC Compiler II 数据手册说明书

DATASHEETOverview IC Compiler™ II is the industry leading place and route solution that delivers best-in-class quality-of-results (QoR) for next-generation designs across all market verticals and process technologies while enabling unprecedented productivity. IC Compiler II includes innovative for flat and hierarchical design planning, early design exploration, congestion aware placement and optimization, clock tree synthesis, advanced node routing convergence, manufacturing compliance, and signoff closure.IC Compiler II is specifically architected to address aggressive performance, power, area (PPA), and time-to-market pressures of leading-edge designs. Key technologies include a pervasively parallel optimization framework, multi-objective global placement, routing driven placement optimization, full flow Arc based concurrent clock and data optimization, total power optimization, multi-pattern and FinFET aware flow and machine learning (ML) driven optimization for fast and predictive design closure. Advanced Fusion technologies offer signoff IR drop driven optimization, PrimeTime ® delay calculation within IC Compiler II, exhaustive path-based analysis (PBA) and signoff ECO within place and route for unmatched QoR and design convergence. F U S I O N D E S I G N P L A T F O R M PrimeTime, StarRC, PrimePower,IC Validator, RedHawk Analysis Fusion Fusion Compiler IC Compiler II Design Compiler NXT TestMAX F o r m a l i t y ECO Fusion S i g n o f f F u s i o n S i g n o f f F u s i o n Test Fusion Figure 1: IC Compiler II Anchor in Synopsys Design PlatformAccelerating DesignClosure on AdvancedDesignsIC Compiler II Industry Leading Place and Route SystemKey BenefitsProductivity• The highest capacity solution that supports 500M+ instances with a scalable and compact data model• A full suite of design planning features including transparent hierarchical optimization• Out-of-the-box simple reference methodology for easy setup• Multi-threaded and distributed computing for all major flow steps• Golden signoff accuracy with direct access to PrimeTime delay calculationPPA• Unified TNS driven optimization framework• Congestion, timing, and power-driven logic re-synthesis• IEEE 1801 UPF/multi-voltage support• Arc-based concurrent clock and data optimization• Global minima driven total power optimizationAdvanced Nodes• Multi-pattern and FinFET aware design flow• Next generation advanced 2D placement and legalization• Routing layer driven optimization, auto NDR, and via pillar optimization• Machine learning driven congestion prediction and DRC closure• Highest level of foundry support and certification for advanced process nodes• IC Validator in the loop signoff driven DRC validation and fixingAdvanced Fusion Technology• Physically aware logic re-synthesis• IR drop driven optimization during all major flow steps• PrimeTime delay calculation based routing optimization for golden accuracy• Integrated PrimeTime ECO flow during routing optimization for fastest turnaround timeEmpowering Design Across Diversified ApplicationsThe dizzying pace of innovation and highly diversified applications across the design spectrum is forcing a complete rethink of the place and route systems to design and implement differentiated designs in a highly competitive semiconductor market on schedule. Designers on emerging process nodes must meet aggressive PPA and productivity goals. It essentially means efficient and intelligent handling of 100s of millions of place-able instances, multiple levels of hierarchy, 1000s of hard macros, 100s of clocks, wide busses, and 10s of modes and corners power domains and complex design constraints and process technology mandates. Emphasis on Designer ProductivityIC Compiler II is architected from the ground up for speed and scalability. Its hierarchical data model consumes 2-3X less memory than conventional tools, boosting the limits of capacity to 500M placeable instances and beyond. Adaptive abstraction and on-the-fly data management minimize memory requirements and enable fast responsive data manipulation. Near-linear multi-core threading of key infrastructural components and core algorithms such as database access and timing analysis speed up optimization at all phases of design. Patented, lossless compact modeling and independent R and C extraction allow handling more modes and corners (MCMM scenarios) with minimal runtime impact.IC Compiler II has built-in Reference Methodology(RM) that ensures fast flow bring up. This RM Flow is Foundry Process/Design Type specific to ensure a robust starting point and seamless bring up. IC Compiler II has direct access to the Golden PrimeTime delay calculation engine to minimize ECO iterations.IC Compiler II’s new data model enables designers to perform fast exploration and floorplanning with complex layout requirements. IC Compiler II can create bus structures, handle designs with n-levels of physical hierarchy, and support Multiply Instantiated Blocks (MIBs) in addition to global route driven pin assignment/feedthrough flow, timing driven macro placement, MV area design planning.A design data mismatch inferencing engine analyzes the quality of inputs and drives construct creation on the fly, delivering design insights even with “incomplete” data early in the design cycle. Concurrent traversal of logical and physical data models enables hierarchical Data-Flow Analysis (DFA) and fast interactive analysis through multi-level design hierarchies and MIBs. Data flow and feedthrough paths highlighted in Figure 2 allow analysis and manipulation through n-levels of hierarchy to complete early design exploration and prototyping.Figure 2: Fast interactive analysis through multiple-levels of physical hierarchy and MIBPipeline-register-planning shown in Figure 3, provides guidance for optimal placement to meet the stringent timing requirementsof high-performance designs. Interactive route editor integrated which is advanced node aware shown in Figure 4, allows intricate editing and routing functions, including the creation of special signal routes, buses, etc.Figure 3: Pipeline register placement enables superior QoR for designs with complex busesAchieving Best Performance, Power, Area, and TATIC Compiler II features a new optimization framework built on global analytics. This Unified TNS Driven Optimization framework is shared with Design Compiler NXT synthesis to enable physically-aware synthesis, layer assignment, and route-based optimization for improved PPA and TAT. Multi-Corner Multi-Mode (MCMM) and Multi-Voltage (MV) aware, level-based analytical algorithms continuously optimize using parallel heuristic algorithms. Multi-factor costing functions deliver faster results on both broad and targeted design goals. Concurrent PPA driven logic remapping, rewiring, and legalization interleaved with placement minimizes congested logic, resulting in simple localized logic cones that maximize routability and QoR.IC Compiler II minimizes leakage with fast and efficient cell-by-cell power selection across HVT, SVT and LVT cells and varying channel lengths. Activity-driven power optimization uses VCD/ SAIF, net toggle rates, or probability functions to drive placement decisions and minimize pin capacitances. Multi-bit register banking optimizes clock tree structures, reduces area, and net length, while automatically managing clock, data, and scan chain connections.Advanced modeling of congestion across all layers highlighted in Figure 4 provides accurate feedback throughput the flow from design planning to post- route optimization.Figure 4: Intelligent and accurate analysis for congestion and powerIC Compiler II introduces a new Concurrent Clock and Data (CCD) analysis and optimization engine that is built-in to every flow step resulting in meeting both aggressive performance and minimizing total power footprint. ARC-based CCD optimization performs clock tree traversal across all modes/corners in path-based fashion to ensure optimal delay budgeting.Robust support for clock distribution enables virtually any clock style, including mesh, multi-source, or H-tree topologies. Advanced analysis and debugging features perform accurate clock QoR analysis and debugging as highlighted in Figure 5.Figure 5: Accurate clock QoR analysis and debugging (a & b) Abstracted clock graph and schematic.(c) Latency clock graph. (d) Colored clock tree in layout.IC Compiler II features many innovative technologies that make it the ideal choice for high-performance, energy-efficient Arm®processor core implementation, resulting in industry-best milliwatts/megahertz (mW/MHz) for mobile and other applications across the board. Synopsys and Arm work closely together to offer optimized implementation of popular Arm cores for IC Compiler II,with reference flows available for Arm Cortex®-A high-performance processors and Mali GPUs. In addition, Arm offers off-the-shelf Artisan® standard cell and memory models that have been optimally tuned and tested for fast deployment in an IC Compiler II environment. Continuous technology innovation and close collaboration makes IC Compiler II the leading choice for Arm-based high- performance design.Highest Level of Advanced Node Certification and SupportIC Compiler II provides advanced node design enablement across major foundries and technology nodes—including 16/14nm,12/10nm, 7/5nm, and sub-5nm geometries. Zroute digital router technology ensures early and full compliance with the latest design rules required for these advanced node technologies. Synopsys collaborates closely with all the leading foundries to ensure that IC Compiler II is the first to deliver support for early prototype design rules and support for the final production design rules. IC Compiler II design technologies maximize the benefits of new process technologies and offer optimal return on investment for cutting-edge silicon applications.IC Compiler II advanced node design support includes multi-pattern/FinFET aware placement and routing, Next-generation advanced 2D placement and legalization, routing layer driven optimization, auto NDR, and via pillar optimization. IC Validator in the loop provides signoff DRC feedback during Implementation.Foundry ﬁll Track based ﬁllFigure 6: IC Validator In-Design metal fill color aware metal fill, optimized for density and foundry requirementsMachine learning driven congestion prediction and DRC closure allow for fastest routing convergence with best PPA. Multiple sets of training data are used to extract key predictive elements that guide the pre-route flow.Advanced Fusion TechnologyThe Fusion Design Platform™ delivers unprecedented full-flow QoR and time-to-results (TTR) to accelerate the next wave of semiconductor industry innovation. The industry’s first AI-enhanced, cloud-ready Design Platform with Fusion Technology™ isbuilt from Synopsys’ market-leading, massively-parallel digital design tools, and augmented with innovative capabilities to tacklethe escalating challenges in cloud computing, automotive, mobile, and IoT market segments and accelerate the next wave of industry innovation.Fusion Technology redefines conventional EDA tool boundaries across synthesis, place-and-route, and signoff, sharing integrated engines across the industry’s premier digital design products. It enables designers to accelerate the delivery of their next-generation designs with the industry-best QoR and the TTR.©2019 Synopsys, Inc. All rights reserved. Synopsys is a trademark of Synopsys, Inc. in the United States and other countries. A list of Synopsys trademarks isavailable at /copyright.html . All other names mentioned herein are trademarks or registered trademarks of their respective owners.。

Moxa CP-114UL 四口RS-232 422 485多口PCI串口板说明书

CP-114UL Series4-port RS-232/422/485Universal PCI serial boards with optional2kV isolationFeatures and Benefits•Over700kbps data throughput for top performance•128-byte FIFO and on-chip H/W,S/W flow control•Universal PCI compatible with3.3/5V PCI and PCI-X•921.6kbps maximum baudrate for fast data transmission•Drivers provided for a broad selection of operating systems,includingWindows and Linux•Easy maintenance with built-in LEDs•Wide-temperature model available for-40to85°C environmentsCertificationsIntroductionMoxa’s CP-114UL Series of multiport serial boards is designed to be used by industrial automation system integrators for long-distance, multipoint,PC-based data acquisition applications.On-chip Automatic Data Direction Control for precision RS-485communication requires precise timing control to enable and disable the line driver.The Moxa Turbo Serial Engine™chip that powers the CP-114UL boards come with on-chip ADDC®,which makes RS-485as easy to use as RS-232.In RS-485mode,the serial port can connect up to31daisy-chained RS-485devices within a range of1.2km.For long-distance RS-485communication,2kV electrical isolation protections are available to prevent equipment damage.Drivers Provided for Windows,Linux,and UNIXMoxa continues to support a wide variety of operating systems,and the CP-114UL boards are no exception.Reliable Windows and Linux/UNIX drivers are provided for all Moxa boards,and other operating systems,such as WEPOS,are also supported for embedded integration.SpecificationsSerial InterfaceComm.Controller MU860(16C550C compatible)Bus32-bit Universal PCIConnector DB44femaleFIFO128bytesMax.No.of Boards per PC8No.of Ports4Serial Standards RS-232,RS-422,RS-485Baudrate50bps to921.6kbpsData Bits5,6,7,8Stop Bits1,1.5,2Flow Control None,RTS/CTS,XON/XOFFParity None,Even,Odd,Space,MarkIsolation CP-114UL-I Series:2kVSerial SignalsRS-232TxD,RxD,RTS,CTS,DTR,DSR,DCD,GNDRS-422Tx+,Tx-,Rx+,Rx-,GNDRS-485-4w Tx+,Tx-,Rx+,Rx-,GNDRS-485-2w Data+,Data-,GNDSerial Software FeaturesWindows Drivers DOS,Windows95/98/ME/NT/2000,Windows XP/2003/Vista/2008/7/8/8.1/10(x86/x64),Windows2008R2/2012/2012R2/2016/2019(x64),Windows Embedded CE5.0/6.0,Windows XP EmbeddedLinux Drivers Linux kernel2.4.x,Linux kernel2.6.x,Linux kernel3.x,Linux kernel4.x,Linux kernel5.x UNIX Drivers QNX6,SCO OpenServer,UnixWare7,Solaris10,FreeBSDPower ParametersInput Current CP-114UL Series:320mA@5VDCCP-114UL-I Series:465mA@5VDCPhysical CharacteristicsDimensions CP-114UL Series:64.4x120mm(2.53x4.72in)CP-114UL-I Series:64.4x130mm(2.53x5.12in)LED InterfaceLED Indicators Built-in Tx,Rx LEDs for each portEnvironmental LimitsOperating Temperature Standard Models:0to55°C(32to131°F)Wide Temp.Models:-40to85°C(-40to185°F)Storage Temperature(package included)-40to85°C(-40to185°F)Ambient Relative Humidity5to95%(non-condensing)Standards and CertificationsEMC EN55032/35EMI CISPR32,FCC Part15B Class BEMS All models:IEC61000-4-2ESD:Contact:4kV;Air:8kVIEC61000-4-3RS:80MHz to1GHz:3V/mCP-114UL-I Series:IEC61000-4-4EFT:Power:1kV;Signal:0.5kVIEC61000-4-5Surge:Power:2kVIEC61000-4-6CS:150kHz to80MHz:3V/m;Signal:3V/mIEC61000-4-8International Approval CP-114UL-DB9M:KCDeclarationGreen Product RoHS,CRoHS,WEEEMTBFTime114,223hrsStandards Telcordia SR332WarrantyWarranty Period5yearsDetails See /warrantyPackage ContentsDevice1x CP-114UL Series serial boardCable1x M44to4x DB9-M cable,50cm(-DB9M models)1x M44to4x DB25-M cable,50cm(-DB25M models) Documentation1x quick installation guide1x substance disclosure table1x warranty cardDimensionsCP-114UL CP-114UL-IOrdering InformationModel Name Serial Bus No.of Serial Ports Serial IsolationProtectionOperating Temp.Included CableCP-114UL w/o Cable Universal PCI4–0to55°C–CP-114UL-T Universal PCI4–-40to85°C–CP-114UL-DB9M Universal PCI4–0to55°C CBL-M44M9x4-50 CP-114UL-DB25M Universal PCI4–0to55°C CBL-M44M25x4-50 CP-114UL-I Universal PCI42kV0to55°C–CP-114UL-I-DB9M Universal PCI42kV0to55°C CBL-M44M9x4-50 CP-114UL-I-DB25M Universal PCI42kV0to55°C CBL-M44M25x4-50Accessories(sold separately)CablesCBL-M44M9x4-50DB44male to DB9male serial cable,50cmCBL-M44M25x4-50M44to4x DB25male serial cable,50cmCBL-F9M9-150DB9female to DB9male serial cable,1.5mCBL-F9M9-20DB9female to DB9male serial cable,20cm©Moxa Inc.All rights reserved.Updated Oct12,2021.This document and any portion thereof may not be reproduced or used in any manner whatsoever without the express written permission of Moxa Inc.Product specifications subject to change without notice.Visit our website for the most up-to-date product information.。

NI PXI定时与同步模块说明书

CONTENTSPXI Timing and Synchronization Modules Detailed View of PXIe-6674TKey FeaturesNI-Sync Application Programming Interface (API) Platform-Based Approach to Test and Measurement PXI InstrumentationHardware ServicesPXI Timing and Synchronization Modules PXIe-6674T, PXIe-6672, PXI-6683 and PXI-6683H•Generate high-stability PXI system reference clocks and high-resolution sample clocks •Minimize skew through access to PXI-star and PXIe-Dstar chassis trigger lines •Import and export system reference clocks for synchronization between multiple chassis orexternal devices •Achieve synchronization over large distance through GPS, IEEE 1588,IRIG-B or PPS•Develop advanced timing and sync applications with NI-Sync and NI-TClk softwarePowerful, Reliable Timing and SynchronizationNI’s PXI timing and synchronization modules enable a higher level of synchronization on the PXI platform through high-stability clocks, high-precision triggering and advanced signal routing. Implementing timing and synchronization hardware can vastly improve the accuracy of measurements, provide advanced triggering schemes, and allow synchronization of multiple devices for extremely high-channel-count applications. NI’s portfolio includes both signal-based and time-based solutions to deliver the advantages of synchronization to numerous applications.Table 1. NI offers various PXI modules to meet a range of timing and synchronization requirements.*Accuracy within one year of calibration adjustment within 0 ºC and 55 ºC operating temperature rangeDetailed View of PXIe-6674TSlot Compatibility PXI Timing or Peripheral Slot PXI or PXIe Hybrid Peripheral Slot PXIe System TimingSlot PXIe System TimingSlot Oscillator Accuracy*TCXO / 3.5 ppm TCXO / 3.5 ppm TCXO / 3.5 ppm OCXO / 80 ppb DDS Clock Generation Range Not available Not available DC to 105 MHz 0.3 Hz to 1 GHzDDS Clock Generation Resolution Not availableNot available0.075 Hz2.84 µHzPXI 10MHz Backplane Clock Override ● ● ● Clock Import Capability ● ● ● Clock Export Capability● ● ● ● Time-Based Synchronization (GPS, IEEE 1588, IRIG-B, PPS)● ● PXI Trigger Access (PXI_TRIG) ● ● ● ● PXI-Star Trigger Access (PXI_STAR) ●● ● PXIe-Dstar Trigger Access (PXI_DSTARA/B/C)● Front Panel Physical Connectors SMB, RJ45SMB, RJ45SMB SMA PFI Lines on Front Panel3366Key FeaturesHigh-Stability, High-Accuracy Onboard ClockApplications requiring highly reliable and consistent clock signals require a highly stable oscillator to avoid clock inaccuracies. For an NI PXI Express chassis, the oscillator is accurate to 25 parts per million (ppm). Inserting an NI PXI timing and synchronization module into the system timing slot of the chassis enables the user to replace this backplane system reference clock using the higher accuracy oscillator of the module. The PXIe-6672 and PXI-6683 modules contain a temperature-compensated crystal oscillator (TCXO) which can achieve accuracies better than 4 ppm. The PXIe-6674T features an oven-controlled crystal oscillator (OCXO) with an accuracy of 80 parts-per-billion (ppb). Note that the PXI-6683H contains the same oscillator as the PXI-6683, but due to its hybrid connectivity is not able to override the backplane clock.Figure 1.By referencing the OCXO on the PXIe-6674T, the 10 MHz backplane clock of a PXI chassis achieves muchlower phase noise and thus more clock stability.PXI modular instruments with phased-lock loop circuits, such as high-speed digitizers and waveform generators, can take advantage of the high-precision clock of timing and synchronization modules. When locking to a high-accuracy reference clock, the instrument inherits the accuracy of the clock, achieving sample clock resolutions as low as 0.5 Hz with an OCXO-based module.Skew Reduction with Star and Differential Star LinesDue to the variation in signal path lengths between slots in a PXI chassis, skew may be introduced when sending clocks or triggers to multiple slot destinations over the PXI trigger bus. To address this, all NI PXI chassis also include trace-length-matched star trigger lines accessible from a timing and synchronization module in the system timing slot. Star trigger lines can reduce skew to a maximum of 1 ns. Additionally, PXI Express chassis include differential star trigger lines capable of minimizing slot-to-slot skew to under 150 ps.Figure 2.While every slot of the PXI backplane may access the PXI trigger bus, the star trigger lines and differential star trigger lines are only accessible through the system timing slot.Time-Based Synchronization with GPS, IEEE 1588, IRIG-B or PPSThe NI PXI-6683 and PXI-6683H timing and synchronization modules synchronize PXI and PXI Express systems through time-based technology or protocols. Time-based modules can generate triggers and clock signals at programmable future times and timestamp input events with the synchronized system time including that of real-time systems. For PXI Express systems requiring time-based synchronization with backplane clock discipline or star trigger access, the PXI-6683H can be combined with the PXIe- 6674T or PXIe-6672 to provide a full-featured synchronization solution.Advanced Routing of Clocks and TriggersUsing a PXI timing and synchronization module provides the capability of advanced routing of clock and trigger signals. Through the combination of system timing slot access and FPGA-based routing, many more source-to-destination routes become possible, allowing more flexible designs and efficient use of system resources.Table 2. The PXIe-6674T timing and synchronization module features a wide vaiety of source-to-destination routes bycombining the power of the PXI Express architecture with the signal-routing capabilities of the onboard FPGA.● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ●●●●●●●NI-Sync Application Programming Interface (API)The NI-Sync driver allows configuration of system timing and synchronization through LabVIEW, C, or .NET. This includes signal-based synchronization, such as sharing triggers and clocks to be used directly, or time-based synchronization, using time protocols such as IEEE-1588, IRIG, or GPS for non-tethered systems. NI-Sync is designed for use with other NI drivers, such as NI-DAQmx, for advanced timing, high channel count, distributed or multiple-instrument applications.DestinationS o u r c ePlatform-Based Approach to Test and MeasurementWhat Is PXI?Powered by software, PXI is a rugged PC-based platform for measurement and automation systems. PXI combines PCI electrical-bus features with the modular, Eurocard packaging of CompactPCI and then adds specialized synchronization buses and key software features. PXI is both a high-performance and low-cost deployment platform for applications such as manufacturing test, military and aerospace, machine monitoring, automotive, and industrial test. Developed in 1997 and launched in 1998, PXI is an open industry standard governed by the PXI Systems Alliance (PXISA), a group of more than 70 companies chartered to promote the PXI standard, ensure interoperability, and maintain the PXI specification.Integrating the Latest Commercial TechnologyBy leveraging the latest commercial technology for our products, we can continually deliver high-performance and high-quality products to our users at a competitive price. The latest PCI Express Gen 3 switches deliver higher data throughput, the latest Intel multicore processors facilitate faster and more efficient parallel (multisite) testing, the latest FPGAs from Xilinx help to push signal processing algorithms to the edge to accelerate measurements, and the latest data converters from TI and ADI continuallyincrease the measurement range and performance of our instrumentation.PXI InstrumentationNI offers more than 600 different PXI modules ranging from DC to mmWave. Because PXI is an open industry standard, nearly 1,500 products are available from more than 70 different instrument vendors. With standard processing and control functions designated to a controller, PXI instruments need to contain only the actual instrumentation circuitry, which provides effective performance in a small footprint. Combined with a chassis and controller, PXI systems feature high-throughput data movement using PCI Express bus interfaces and sub-nanosecond synchronization with integrated timing and triggering.OscilloscopesSample at speeds up to 12.5 GS/s with 5 GHz of analog bandwidth, featuring numerous triggering modes and deep onboard memoryDigital InstrumentsPerform characterization and production test of semiconductor devices with timing sets and per channel pin parametric measurement unit (PPMU)Frequency Counters Perform counter timer tasks such as event counting and encoder position, period, pulse, and frequency measurementsPower Supplies & Loads Supply programmable DC power, with some modules including isolated channels, output disconnect functionality, and remote senseSwitches (Matrix & MUX) Feature a variety of relay types and row/column configurations to simplify wiring in automated test systemsGPIB, Serial, & Ethernet Integrate non-PXI instruments into a PXI system through various instrument control interfaces Digital MultimetersPerform voltage (up to 1000 V), current (up to 3A), resistance, inductance, capacitance, and frequency/period measurements, as well as diode testsWaveform Generators Generate standard functions including sine, square, triangle, and ramp as well as user-defined, arbitrary waveformsSource Measure Units Combine high-precision source and measure capability with high channel density, deterministic hardware sequencing, and SourceAdapt transient optimizationFlexRIO Custom Instruments & Processing Provide high-performance I/O and powerful FPGAs for applications that require more than standard instruments can offerVector Signal Transceivers Combine a vector signal generator and vector signal analyzer with FPGA-based, real-time signal processing and controlData Acquisition Modules Provide a mix of analog I/O, digital I/O, counter/timer, and trigger functionality for measuring electricalor physical phenomena©2019 National Instruments. All rights reserved. LabVIEW, National Instruments, NI, NI TestStand, and are trademarks of National Instruments. Other product and company names listed are trademarks or trade names of their respective companies. The contents of this Site could contain technical inaccuracies, typographical errors or out-of-date information. Information may be updated or changed at any time, without notice. Visit /manuals for the latest information. Hardware ServicesAll NI hardware includes a one-year warranty for basic repair coverage, and calibration in adherence to NI specifications prior to shipment. PXI Systems also include basic assembly and a functional test. NI offers additional entitlements to improve uptime and lower maintenance costs with service programs for hardware. Learn more at /services/hardware .Program Duration 3 or 5 years3 or 5 years Length of service programExtended Repair Coverage●●NI restores your device’s functionality and includes firmware updates and factory calibration.SystemConfiguration,Assembly, and Test 1 ● ●NI technicians assemble, install software in, and test your system per your custom configuration prior to shipment.Advanced Replacement 2 ●NI stocks replacement hardware that can be shipped immediately if a repair is needed.System Return MaterialAuthorization (RMA)1 ●NI accepts the delivery of fully assembled systems when performing repair services.Calibration Plan (Optional) Standard Expedited 3NI performs the requested level of calibration at the specified calibration interval for the duration of the service program.1This option is only available for PXI, CompactRIO, and CompactDAQ systems.2This option is not available for all products in all countries. Contact your local NI sales engineer to confirm availability. 3Expedited calibration only includes traceable levels.PremiumPlus Service ProgramNI can customize the offerings listed above, or offer additional entitlements such as on-site calibration, custom sparing, and life-cycle services through a PremiumPlus Service Program. Contact your NI sales representative to learn more.Technical SupportEvery NI system includes a 30-day trial for phone and e-mail support from NI engineers, which can be extended through a Software Service Program (SSP) membership. NI has more than 400 support engineers available around the globe to provide local support in more than 30 languages. Additionally, take advantage of NI’s award winning online resources and communities .。

FDA指导原则-Guidance for industry-Rheumatoid Arthritis-Developing Drug Products for Treatment

1350 Piccard Drive, Rockville, MD 20850-4307
DSMICA E-mail: dsmica@; DSMICA Fax: 301-443-8818
(Tel) Manufacturers Assistance: 800-638-2041 or 301-443-6597
or
Office of Communication, Outreach, and Development, HFM-40
Center for Biologics Evaluation and Research, Food and Drug Administration
1401 Rockville Pike, Suite 200N, Rockville, MD 20852-1448
I.
INTRODUCTION
The purpose of this guidance is to outline the FDA’s current thinking on the principles of clinical development relevant to dose-selection and assessment of efficacy and safety to support the approval of drug products for the treatment of patients with rheumatoid arthritis (RA). It also addresses additional considerations for drug products developed as drug-device combination products. This guidance does not address nonclinical development, development of drug products for juvenile idiopathic arthritis, or development of biosimilar products. This guidance revises the guidance for industry Clinical Development Programs for Drugs, Devices, and Biological Products for the Treatment of Rheumatoid Arthritis (RA), published in February 1999.2 After it has been finalized, this guidance will replace the February 1999 guidance and will reflect the current thinking of the FDA on RA drug product development. The FDA’s current thinking has been influenced by clinical development programs conducted for RA since the 1999 guidance published, and by changes in the standard of care for RA because of availability of many effective treatments. The revisions include: Dose(s) and dosing regimen(s) selection throughout the clinical development program Expectations for establishing efficacy in RA based on signs and symptoms and physical function domains

1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。