标签: standard

I was recently looking back at my first trip to Europe in 1992. We spent time in England, the Netherlands, Germany, Denmark, Sweden, Norway, and then Germany again and back to England over a three-week period. We slept on planes, boats, and trains. We managed to pull off this trip before we had cell phones or the Internet. It was also before the euro, so we were constantly exchanging money as we left and entered countries. We also fumbled with some language translation books when trying to communicate with the natives; there were no apps yet or devices to use them. The trip went very well. The only hiccup: We once got on a train going in the wrong direction. With the transportation infrastructure there, it didn't take too long to get back on the right track. The trip got me to thinking about communications and standards. (I know, what an engineering nerd thing to do, right?) Actually, I confess that is a little backward. Thinking about the P1687 proposed IEEE standard brought the European trip to mind. Why is that? The complexity of today's ICs is somewhat analogous to the complexities we encountered when planning and executing the trip. We had to deal with different travel methods, languages, currencies, and cultures in a condensed amount of time. Complex ICs contain many different parts and pieces that have to work together. These can include multiple power levels, on-chip clocks, tons of memories, CPUs, protocols, lots of IP (intellectual property and, in some cases, Internet protocol), sensors, and more.   IJTAG lets all IP speak the same language. I work in the design-for-test area, so I can attest that finding a way to access, integrate, and test the different parts and pieces of an IC is quite a challenge. I believe that IEEE P1687 is a great help and enabler for designers and test engineers to accomplish their tasks. P1687, sometimes call IJTAG (the "I" stands for "internal") works along with the IEEE 1149.1 standard JTAG interface prevalent on most ICs. IJTAG is basically an IP and test procedure reuse methodology. It provides a general-access test mechanism to the embedded IP within all levels of the design hierarchy. Having IJTAG compliant IP and test instruments in a design greatly simplifies complex test procedures. Test procedures or sequences written at the IP interface level can be remapped automatically to the top level of the design, regardless of where the IP sits in the hierarchy. All the IP throughout the design can be integrated into a test network that most efficiently completes the testing of all the pieces. In essence, using IJTAG compliant IP in the design means all the parts will speak the same language. Communication and productivity go up in a way similar to how the euro made it easier to travel among many European countries. For a more detailed explanation of how IJTAG works, I encourage you to view this short video. If you really want to know the details of the IEEE P1687 proposed standard, then see the details. Much as IJTAG can make IP access, control, and test easier, I expect my next visit to Europe to be easier now that we have cell phones, the Internet, apps, and the euro. I think I'll head for the southern countries, and it will be more of a relaxing holiday. It should be a breeze with the tools and standards now available. Bruce Swanson Technical Marketing Engineer Mentor Graphics  

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

技术文档:Windows Embedded Standard7组件化、工具和映像创建 Windows Embedded Standard7概述 技术文档:Windows Embedded Standard7组件化、工具和映像创建。本文档将Windows Embedded Standard 7与 Windows Embedded Standard 2009在组件化、工具和映像创建等方面的对比 概述 本文介绍了Windows Embedded Standard 2009和Windows Embedded Standard 7在组件化、工具和映像构建流程等方面的部分不同。目的是使用户深入了解这两款 嵌入式产品 之间的差异，以及这两款产品在创建和部署 嵌入式 设备映像时在功能、工具和用户整体体验方面的部分不同。 组件化对比 本文将比较Windows Embedded Standard 2009和Windows Embedded Standard 7在以下方面的不同： ·    组件架构 ·    功能集包 ·    驱动程序包 ·    语言包 ·    组件依赖关系 ·    宏组件与模板 ·    SMI（Settings Management Infrastructure，设置管理架构）的设置与配置设置 ·    嵌入式功能（EEFs） ·    客户化组件支持 文档下载 http://www.msembed.com/upload/Windows_Embedded_Standard_7_VS_2009.doc 更多信息 Windows Embedded Standard7讨论区请猛击：http://bbs.msembed.com/WindowsStandard7/list.aspx Windows Embedded Standard7专题请猛击： http://www.msembed.com/WindowsEmbeddedStandard7