标签: interface

DDR3 SDRAM物理层（PHY）的控制器（PUB）内置了DDL VT补偿与I/O阻抗校准功能，这两个功能可在DFI Update请求中由控制器触发完成，或者是PHY触发完成。DFI Update接口时序需要符合DFI 2.1协议中对Update接口的要求。 1 DFI Update的两种工作方式 在DFI Update的两种方式中，采用存储控制器触发的Update是由控制器控制何时来进行DFI Update，在Update过程中控制器周期性的向PHY发送Update命令，并保证在整个Update过程中没有任何的数据请求访问PHY。而PHY触发的Update则是由PHY来决定何时进行Update。当PHY内部的检测机制检测到PHY需要进行Update时，就会通过DFI Update接口向控制器发送Update请求，在一定时间内控制需要停止所有对PHY的数据请求访问，并通过DFI Update接口回应PHY的请求，直到PHY撤销Update请求。 这两种方式各有各的好处，控制器触发的Update可由控制根据数据通路的闲忙状态，选择性的向PHY发送Update请求，以达到最佳的性能指标。而PHY触发的Update则能够实时更新PHY内部状态，使PHY的时序能够保持在最佳状态。在GK6202S中，MC（DDR3存储控制器）仅采用了控制器触发完成Update的方式，并且不支持PHY来触发Update的方式。 以下为Update中DDL VT补偿与I/O阻抗校准功能的详细说明。 2 DDL VT补偿原理 2.1 功能概述 在芯片操作时，电压与温度都会随着运行时间增加而变化。PUB中包含了VT漂移补偿逻辑，用来动态地调整延迟单元的延迟选择输入，以保持延迟单元的延时为一个固定值。DATX8中的DDL都是可以进行补偿的，而AC中的DDL则不能进行补偿。AC中的DDL都是用来匹配DATX8中的数据路径的，所以不会对这些延迟设置0以外的值。 一旦使能VT补偿功能，DATX8中的主延迟线（MDL）会持续的以选择的延迟时间为单位测量DDR的时钟。在每个更新周期内，由VT漂移造成的变化，将会传递到其他的延迟线状态机中，以适应期望的延迟时间。每个延迟线的更新使能可通过配置 PGCR0-2 寄存器。 在初始校准或数据训练被触发时，MDL控制逻辑将第一次测量的MDL周期存储为MDL校准周期，前期MDL校准周期和当前MDL校准周期。 在MDL初始校准之后，MDL会继续周期性的进行周期测量。随后每一次的测量MDL周期都会被存储为当前的校准周期。如果当前周期与前期周期不符，且超过PGCR.DLDLMT规定的VT阈值，VT漂移补偿就会开启。 参考PUB文档420页，“VT Drift Status and Update Timing” 可得到更详细的VT漂移状态与VT更新时序描述。 DATX8中需要补偿的延时参数可通过以下公式得到： DLnew=MDLnew/MDLinit*DLinit MDLinit为初始MDL校准周期（IPRD） MDLnew为当前MDL校准周期（TPRD） DLinit为初始延迟线的延迟选择值，与MDLinit一起计算得到 DLnew为延迟线的VT补偿值 当MDL周期的变化被检查到，VT补偿逻辑就就会计算出DDL的VT补偿值。此计算结果会被存储到一个内部本地寄存器里，并且在VT更新被PUB触发前都不会被使用到DDL上去。 例如：在针对DDL VT补偿的仿真验证中，我们观察到了整个DDL VT补偿的过程。从过程上看，分为三个步骤： 1. TPRD的检测与计算 2. VT补偿值的计算 3. 等待DFI Update触发，更新DDL的延迟值 下面，我们从这三个步骤来描述整个DDL VT补偿的过程： 2.2 TPRD的检测与计算 在PUB内的init_phy中，MDL中TPRD的计算在dx_ctl .init_lcdl_dx_mdl（以下简称MDL模块）模块中完成计算。在MDL模块中，TPRD的计算分为两级，首先是measure_probe的计算，然后通过measure_probe的结果来计算TPRD。 measure_probe的计算总共有8个迭代步骤，在初始状态下会被初始化为0x80，根据PHY反馈的cal_out信号来对measure_probe进行操作，cal_out为1时对measure_probe进行减操作，cal_out为0时对measure_probe进行加操作。这一级对measure_probe的计算约为1400ns的时间。 这里写图片描述 得到measure_probe后，average_period在每次cal_average信号为1时与measure_probe的值相加。然后cfg_tprd_16x的计算过程则是将cfg_tprd_16x本身的值减去cfg_tprd_16x/2再加上average_period。在mdl_cal_update为1时将cfg_tprd_16x的值作为TPRD输出个其他的DDL计算模块。这一级的计算时间约为11148ns。 这里写图片描述 2.3 VT补偿值的计算 当TPRD完成计算后，会将cfg_tprd_16x信号输出到每个lcdl与bdl的延迟计算单元。在这些延迟计算单元中都实例化了同一个计算模块——u_DWC_ddr3phy_init_ddl_vtcomp。此模块的功能就是将cfg_tprd_16x的值转化成LCDL与BDL等DDL中可识别的dly_sel，同时也将这些翻译过了的值传输给配置寄存器，以供外部访问。 具体计算过程就不详细描述。 当LCDL与BDL的所有延迟单元需要更新的延迟值都已经计算完毕时，u_DWC_ddr3phy_init_phy模块就会想外部控制模块发起vt_drift请求，表示此时VT补偿的计算已经完成，等待外部响应，一旦响应更新值就会更新到各个DDL中去。 2.4 等待DFI Update触发，更新DDL的延迟值 在PUB中，共有三种vt_drift的协议，如下图所示： 这里写图片描述 第一种协议：当PHY完成补偿计算后就会将vt_drift信号拉高，而PUB则会根据DFI端口Update的情况在控制器空闲状态时将vt_update信号拉高，此时在T4周期表示当前的VT补偿值都已经更新到DDL中去了。 第二种协议：在第一种协议的基础上，若在T4周期时又有一次新的补偿计算完成，那么在两个周期后vt_drift拉高的同时，vt_update也会同时拉高。从而将最新的VT补偿结果更新到DDL中。 第三种协议：在第一种协议的基础上，在T4周期后，若PUB能够从DFI Update中得知控制仍然处于空闲状态或自刷新状态，那么PUB就会将vt_update一直保持高电平，以保证DDL中的VT补偿的结果是最新的。此时每一次vt_drift拉高都只需要一拍就可以完成VT补偿值的更新。 2.5 禁止VT计算过程 当我们手动配置DXnLCDLR0-2与DXnBDLR0-4寄存器时，延迟线的VT计算应该被禁止。以下为禁止VT计算的流程： 1. Write DXCCR (MDLEN) = 1’b0 2. Write PGCR1 (INHVT) = 1’b1 to stop VT compensation and write PGCR =8’b0 to prevent a PHY initiated DFI update request 3. Write PGCR0 = 6’b000000 OR disable the DFI update interface from issuing controller initiated DFI updates 4. Wait for approximately 5000 clock periods for all Master Delay Lines to complete the calibration 5. Calibrations will be completed and the DXnMDLR registers can be written. 6. To re-enable master delay line calibrations, VT calculations and VT compensation 7. Write DXCCR (MDLEN) = 1’b1 8. Write PGCR1 (INHVT) = 1’b0 9. Write PGCR0 = 6’b111111 10. System ready 3 阻抗校准原理 这里写图片描述 如上图所示参与阻抗校准的单元主要有三个：*_PZQ模块，位于IO；*_VREF模块，位于IO；阻抗控制单元（数字电路），位于PUB。 可校准内容： 1、ODT pull-up 2、ODT pull-down 3、驱动电阻 pull-up 4、驱动电阻 pull-down 阻抗控制单元通过ZCTRL将阻抗码输出至每一个VREF单元。VREF单元进行解码，并通过ZIOH总线传输给每一个功能IO单元以及*_PZQ单元。PZQ单元将VREF发来的阻抗码与外接电阻进行比较，并将结果通过ZCOMP反馈给阻抗控制单元。阻抗控制单元根据比较结果调整ZCTRL的值。直到阻抗码与外接电阻相匹配。阻抗控制单通过ZCAL来选择对哪一个电阻进行校准。 阻抗校准可分为以下三种方式，但是在整个Update过程中，PUB都是使用Direct Calibration方式来进行校准的。 A. Direct Calibration，使用ZPROG设置 在此模式下，用户仅需要配置ODT(ZPROG )与驱动电阻(ZPROG )，并运行阻抗校准单元内的自动校准程序。在内部程序中，ODT与驱动电阻的上、下拉电阻会独立进行校准。 B. Override Setting，使用ctrl_ovrd_data设置 在此模式下，用户不需要使用校准循环，仅需直接配置zctrl_ovrd_data 来控制阻抗值。共有32个可编程序列，每一种序列代表一个阻抗值，此阻抗值与corner有关。 例如，假设电流为I，校准电压为VREF，那么序列N的可编程阻值为： Zprog = K * VREF / (N * I ) K为校正因子，近似于1 具体阻值可参考PHY文档中的表格，《dwc_ddr32_phy_gf40lp25_db》第96页。 C. Custom Calibration，在使用ZPROG基础上，进行扩展校准 此模式为前两种模式的结合，可分成两步完成： 1、用户提供一个ZPROG的值，并记录下ZCTRL的值。 2、用户通过计算ZCTRL的值，来对阻抗进行override。 例如：需要得到一个ZO 为18 ohm的阻抗 1、用户执行直接校准ZO为36 ohm，此时pull-up index = 12，pull-down index = 13。 2、计算18 ohm的index，index不得大于31 pull-down (36/18) * 13 = 26 pull-up (36/18) * 12 = 24 ———————————————— 版权声明：本文为CSDN博主「hierro_sic」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/hierro_zs/java/article/details/62429705

Part 1 focused on the concept of IP being a partnership between the IP supplier and the user. Part 2 asked whether IP is too complex for start-ups. In Part 3 , we looked at IP and sub-systems. Taking part in this discussion are: Mike Gianfagna, vice president of corporate marketing at Atrenta; Warren Savage, CEO of IPextreme; John Koeter, vice president of marketing at the solutions group of Synopsys; and Chris Rowen, Cadence Fellow and CTO of Tensilica. Brian Bailey: We talked about standards as they relate to the hardware interfaces. What about standards within IP itself—how we package them, how we ship them, how they integrate? John Koeter: There's a lot of standards such as GDSII, LEF, .lib files, Verilog... Warren Savage: Those are all driven from EDA compatibility. They're not functional in any form... Brian Bailey: We've got IP-XACT, System RTL, but that's about it at the moment, isn't it? Warren Savage: Somebody from one of the large semiconductor companies said to me, where are the standards on deliverables? We work with the GSA IP working group, and it's a topic that comes up. But when you talk about deliverables, it doesn't seem like anyone's doing anything dramatically different from the other guys. It seems like it's not that big of a problem, although people would love it to be checklist-based with a standard road map. Mike Gianfagna: That's one of the things that is on our road map. We've done a lot of work verifying the completeness of IP—now what about packaging, creating a package that allows it to be reusable? How do you leverage what you know to the next step? That is something that we're working on. But is there a standard out there? No. Chris Rowen: The hardware side has turned out to be easier than the software side. I was surprised in the evolution of Tensilica that we so easily satisfied the expectations of the hardware teams in terms of deliverables. With soft IP, if you're delivering RTL and test benches and verification environments and exhaustive documentation and scripts for every known CAD tool, you're in pretty good shape. But on the software side in terms of compilers, debuggers, 14 different RTOSes, all these different graphical user interfaces, 10 different debug ports—it's an unbounded number of things. Getting people to stabilise their expectations on the software side is actually taking longer. That's the beauty of software; it doesn't have any hard limits in terms of what people expect it to be and do. They expect it to do anything, anytime, anywhere, and support the beta standard that was never thought of at the time that we originally signed the deal. Brian Bailey: Two of our panelists are IP developers now within large EDA companies. Does that create any problems? Chris Rowen: I think the only answer I can make at this point is it's too soon to know. John Koeter: There are firewalls where appropriate. Our services organisation, field organisation, and our tools work with ARM cores—hardening ARM cores, often using or perhaps using ARM libraries, or memories. We have firewalled that off from any access to the IP groups. We don't allow certain groups to talk to other groups, because there may be a conflict of interest. It is something you have to be good at. Chris Rowen: Right, and I think that the situation for Tensilica is really the dual of what John says—the EDA industry has worked out some principles for handling this kind of situation and they seem to be allowing customers to be successful, and that's the important thing.   Brian Bailey EE Times

Part 1 looked into the idea of IP being a partnership between the IP supplier and the user. Part 2 asked whether IP is too complex for start-ups. In Part 3 , we looked at IP and sub-systems. Taking part in this discussion are: Mike Gianfagna, vice president of corporate marketing at Atrenta; Warren Savage, CEO of IPextreme; John Koeter, vice president of marketing at the solutions group of Synopsys; and Chris Rowen, Cadence Fellow and CTO of Tensilica. Brian Bailey: We talked about standards as they relate to the hardware interfaces. What about standards within IP itself—how we package them, how we ship them, how they integrate? John Koeter: There's a lot of standards such as GDSII, LEF, .lib files, Verilog... Warren Savage: Those are all driven from EDA compatibility. They're not functional in any form... Brian Bailey: We've got IP-XACT, System RTL, but that's about it at the moment, isn't it? Warren Savage: Somebody from one of the large semiconductor companies said to me, where are the standards on deliverables? We work with the GSA IP working group, and it's a topic that comes up. But when you talk about deliverables, it doesn't seem like anyone's doing anything dramatically different from the other guys. It seems like it's not that big of a problem, although people would love it to be checklist-based with a standard road map. Mike Gianfagna: That's one of the things that is on our road map. We've done a lot of work verifying the completeness of IP—now what about packaging, creating a package that allows it to be reusable? How do you leverage what you know to the next step? That is something that we're working on. But is there a standard out there? No. Chris Rowen: The hardware side has turned out to be easier than the software side. I was surprised in the evolution of Tensilica that we so easily satisfied the expectations of the hardware teams in terms of deliverables. With soft IP, if you're delivering RTL and test benches and verification environments and exhaustive documentation and scripts for every known CAD tool, you're in pretty good shape. But on the software side in terms of compilers, debuggers, 14 different RTOSes, all these different graphical user interfaces, 10 different debug ports—it's an unbounded number of things. Getting people to stabilise their expectations on the software side is actually taking longer. That's the beauty of software; it doesn't have any hard limits in terms of what people expect it to be and do. They expect it to do anything, anytime, anywhere, and support the beta standard that was never thought of at the time that we originally signed the deal. Brian Bailey: Two of our panelists are IP developers now within large EDA companies. Does that create any problems? Chris Rowen: I think the only answer I can make at this point is it's too soon to know. John Koeter: There are firewalls where appropriate. Our services organisation, field organisation, and our tools work with ARM cores—hardening ARM cores, often using or perhaps using ARM libraries, or memories. We have firewalled that off from any access to the IP groups. We don't allow certain groups to talk to other groups, because there may be a conflict of interest. It is something you have to be good at. Chris Rowen: Right, and I think that the situation for Tensilica is really the dual of what John says—the EDA industry has worked out some principles for handling this kind of situation and they seem to be allowing customers to be successful, and that's the important thing.   Brian Bailey EE Times

Serial digital interface(SDI) is a standard for high quality lossless digital video transmission.   Depending on the data rate there are different variants of SDI: - SD-SDI carries NTSC/PAL video data with a data rate of 270Mbps - HD-SDI carries High Definition videos with a data rate of 1.485Gbps - 3G-SDI carries 1080p50 videos with a data rate of 2.97Gbps - Dual - Stream SDI carries two independent HD video streams in a single link. This results in a data rate of 2.97Gbps   The greatest advantage of SDI is being able to transfer high- definition video signals without any loss of quality. This is due to the fact that the video is transferred in uncompressed format. A video network based on SDI can be easily put together with a readily available 75 ohm co-axial cable between a transmitter and a receiver. Because of these benefits, SDI is rapidly becoming the leading video format for digital video transmission.   One of our recent designs involved an SDI transmit and receive, both working at 3G data rate. The scope of our project required that we output processed video streams on the SDI interface. We integrated a high-end video processor from TI along with a Spartan – 6 FPGA from Xilinx for this. The SDI physical interface was implemented by integrating an SDI core inside the FPGA. The SDI core mainly uses two clocks, one a Reference clock and  the other a pixel clock. The reference clock is a fixed LVDS clock input while the pixel clock is the one to which the parallel video data is synchronized from the processor. For proper functionality, SDI core expects both data and reference clocks to be in complete phase synchronization.   The main challenge that we faced in bringing up SDI-TX was in achieving synchronization between the processor’s pixel clock and the reference clock fed to the SDI core. To mitigate this, we added a FIFO in FPGA and used an internally generated clock inside the SDI core, as a FIFO read clock, with pixel clock being used as FIFO write clock. Although this resulted in phase synchronization, there were frequent underflow and overflow of FIFO due to minute frequency jitter among these clocks. To eliminate this, we had to find a common clock source for the pixel clock and the SDI core’s reference clock . To accomplish this, we connected a clock from FPGA, generated from SDI core reference clock, to an auxiliary clock input of the processor. Since the processor now derived the pixel clock using this auxiliary clock input, the FIFO overflow/underflow issue got resolved. Synchronization with the processor was not an issue for the SDI-RX path since the SDI-Core in itself generates pixel clock.   The second major problem that we encountered was with respect to Dual-stream SDI. To give DS-SDI output, SDI core requires two parallel video inputs which are frame synchronized. In our design, the processor was giving out two parallel video outputs to FPGA and it was not possible to achieve frame synchronization at the source. Thus, the FPGA had to align the two video frames before routing it to SDI core. Here we used a DDR3 connected to FPGA to achieve frame alignment. One of the incoming video stream data was written to DDR3 continuously beginning from the start of the frame, along with checking for start of frame in second video stream. Once the start-of-frame in second video data is detected, this stream along with the first stream, is sent to SDI core for generation of DS-SDI. The data from the first stream is not live in the sense that a stored frame is being read back from DDR3. It has to be noted that the size of the DDR3 memory must be big enough to store one complete frame.   The design of an SDI system not only involves proper understanding of the SDI core architecture but also careful high-speed design. In addition, a major aspect to getting the interface to work flawlessly is a robust PCB design. This becomes extremely important since the data rate in SDI line can go upto 2.97Gbps. The main objective of PCB layout design is to achieve uniform impedance along the entire trace. This included careful selection of series components on the trace, trace width selection, trace separation for differential lines etc. Since our design involved both SDI receive and transmit, we made sure that there was good enough separation between TX and RX circuits to avoid any interference.   - Suresha N S, Harshith Kasyap and Alagappan Ramanathan

贴几个汽车诊断接口OBDII的接口和保护电路 最近在设计车载GPS，发现这个OBDII接口极为通用，而且若能与车载电脑ECU联网，将能活动很多汽车信息，并且可以INTERNET互联,应用很广泛，而且将有极为丰富的用户体验 elm327 demonstration board circuit schematic   elm327 + cp2102 as usb convert to uart LP2951 Schematic circuit of OBDII interface adapter