BASIL Networks BN'B

Part 18: IoT Core Platform Development;- Peripheral I/O Device Design
The IoT Embedded Core Platform -Peripheral Devices Real World Testing - Continued

"Learning is the beginning of wealth.  Learning is the beginning of health.  Learning is the beginning of spirituality. Searching and learning is where the miracle process all begins."   John Rohn (Sept 17, 1930  - Dec 5th, 2009)

Part 1 Introduction - Setting the Atmosphere for the Series (September 26, 2016)
Part 2 IPv4, IPv6 - The Ins and Outs of IP Internet Addressing  (November 11, 2016)
Part 3 IPv4, IPv6 DHCP, SLAAC and Private Networks - The Automatic Assignment of IP Addressing  (November 24, 2016)
Part 4 Network Protocols - Network, Transport & Application (January 10, 2017)
Part 5 Network Protocols - Network, Transport & Application -Continued (Aug 17, 2017)
Part 6 Network Protocols - Network, Transport & Application -Continued -Ethernet Protocol (Sept 21, 2017)
Part 7 Network Protocols - Network, Transport & Application -Continued -The CRC-32 and Checksums(Nov 23, 2017)
Part 8 IoT Core Platform - SoC Core Processor of Embedded Systems (Jan 12, 2018)
Part 9 IoT Core Platform - SoC Core Processor of Embedded Systems-Vulnerabilities (Mar 16, 2018)
Part 10 IoT Core Platform - SoC Core Processor of Embedded Systems-Product Development Management (Apr 5, 2018)
Part 11 IoT Core Platform - SoC Core Processor of Embedded Systems -Documentation Management Processes (June 27, 2018)
Part 12 IoT Core Platform - IoT Core Platform - Peripherals -Documentation Management Processes (July 29, 2018)
Part 13 IoT Core Platform - Peripheral Interface Devices  -Peripheral Design From the Beginning  (Oct 7, 2018)
Part 14 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design (Oct 29, 2018)
Part 15 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design-Continued (Dec 7, 2018)
Part 16 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design-Continued (Feb 11, 2019)
Part 17 IoT Core Platform - Peripheral I/O Development - Peripheral Device Real World Testing -Continued(Mar 15, 2019)

Quick review to set the atmosphere for Part 18:
To be able to share some wisdom that the author has experienced over the years is part of what mentoring and educations is about.  During the process of product development for a small company verses a large company the differences are in how the resources are managed.  During my career I have been fortunate to have a few mentors that were, as we would say today, not very politically correct.  My mentors were very strong minded and independent scientists and engineers that have been through the "melting pot".  They shared their experiences of designing for manufacturing and that as a design engineer you become part of the product and if an error shows up in manufacturing you are responsible to fix it - period.  That is, you are responsible for your designs throughout the manufacturing process until it is running smooth while maintaining your current project assigned, in simple words - if you designed the product you smooth out any issues to insure a smooth manufacturing process.  Today with outsourcing both design and manufacturing that process is next to impossible to implement for a large company, however for a small company or startup it would be advantageous to insure some in-house expertise so you company is not destroyed for the failure of outside sources to fix.

 Over time designers fell in to the commodity level until recently when true engineering talent became difficult to keep at a company, unfortunately having discussions with corporate managers and engineers the frustration of being tossed around from project to project has taken its tool on talented designers as well as the intense demands on designers today.

OK, as we stated in part 16 we will not be able to cover all the ITF development in a single presentation/part so we will break this down and present the ITF development in a few sequential parts for the series. Just a short change in direction, however a better validation to complete the objective.

From the previous Internet of Things Part-1 through Part- 16 have brought us to this level of what we want in an IoT core Platform.  The real time development process is far from being a linear process from conception to finished product.  Over the past 40 plus years that I have been involved with product design, research, investigations and management so much has changed.

Isolation is the big issue with testing in order to eliminate or reduce interaction the test equipment will have on the Proof of Design build.

Oh, by the way we did mention that we were going to use two CPLD's, the logic will show itself shortly.

What we want to cover in Part 18:
In Part-16 we presented that  fact that we should address testing of the peripherals (Proof of Design) PoD with a prototype build to insure when we interconnect several of the peripherals the throughput required for the applications will be met.  This also put us in a position to change the development direction from the peripheral that we have to developing a test methodology that will be used for testing the remaining peripherals for the platform.  With that stated we will continue moving forward with detailing the Interface Test Fixture (ITF), creating a schematic and PCB layout for the ITF, not all in this part though since it is a relatively large development.  The ITF is a project with multiple sections for testing the IoT Platform and peripherals so we will take perform the development in sections as well.

Updating the IPD project documentation for the Interface Test Fixture to keep track of the development process, "Documentation is a living process during development".   

Several changes have been incorporated for the PoD build and the ITF In-Circuit-Programming Isolated section that we will document for future PoD and manufacture intent builds.

Expanding on the ITF functional block diagram Figure 16.1 the following sections documentation will be created to incorporate into the Interactive Product Development System.

This part will present the Schematic diagrams for the In-Circuit-Programming section for the top five CPLD manufacturers and their proprietary ISP module that we will interface and translate to a single ISP JTAG interface for the ITF.

• The Updates to the CPLD, FPGA JTAG interface connectors
• The CPLD, FPGA In System Programming Model Block Diagram
• The CPLD, FPGA ISP Isolation Schematic diagram
• The CPLD, FPGA ISP Isolation Assembly Layout
• The CPLD, FPGA ISP Isolation PCB Top/Bottom Etch
• The raw material cost for the PCB build/
• How to Obtain a Finished ISP ITF Section
• SUMMARY

Lets Get Started:
The IPD Documentation - Developing Documentation Discipline
Remember changing direction overnight does not mean changing goals or the final destination, it is just a better way to insure you will reach them.  In my years of exposure to the design arena as a designer and mentor I have had the honor of experiencing innovative and passionate creators to realize that the thought process of creative passion is not a linear step function, 1, 2, 3 ...N, probably because humans are not robots, that follow a preprogrammed set of processes as some may think.  The innovation of the human mind subconsciously is always performing scenarios to find the best solution for the task at hand.

OK, when we were discussing this project the question came up, Why did you select to use two CPLDs in stead of just on FPGA?  These are the results of that discussion, to review what was stated earlier.  The first reason is we selected MAX line of CPLDs was purely out of the experience level over the years we have used them.  The second reason we selected Intel®/Altera® is the way Altera archives the older revisions of  software on their website, both by date, revision number and the chips supported.  Another factor that weighted it was the amount of resources required to use the latest release of the software of all CPLD/FPGA manufacturers.  

Intel/Altera new release with a 12GB local DRAM would compile the AD-CHAN  MAX-II CPLD OK, however we ran out of memory for the timing diagrams.  All the older releases run on 8GB DRAM/4GB DRAM on the x32 systems easily while the latest release states up to 32GB DRAM or more.  for some of the features.

This would require the majority of small companies and entrepreneurs to purchase the latest and greatest motherboards or desktops that supports that amount of memory.  The majority of older desktop motherboards are limited to 16GB including the Graphics memory and many of the laptops are limited to 8GB that are only a couple of years old.  Another deciding point of using two CPLDs you double the number of I/O pins that should cover this ITF design easily and have some logic Elements to spare for feature expansion and design changes.

OK, a quick review of the documentation system we will be using, Yes again, Ok I'm sounding like management now, - so what does that all mean to this series?  This means that to assist this innovative development process that may change direction at times from one development task to another a tracking system should meet the following requirements.

1. Interactive - by second nature without thought
2. Flexibility - being able to record changes and additions in real time.  During development changes in one project can easily effect another project.
3. Multiple Project Tracking - This is where we are now - being able to start and track new projects that will eventually interact with the product development at hand, hence: the IoT Core Platform development project.
   So, lets give the ITF a Project name- Universal_Peripheral_ITF for lack of a better one.
   AND-- We are going to make some changes, again---

Repetition is the mother of retention,  wait a minute!..., I think I read that somewhere before.

CPLD, FPGA In Circuit Programming Model:
Since we are using CPLDs only on this ITF design we will start at the In-System-Programming (ISP) configuration.  This looks like and generally is a simple connection to program a CPLD on an assembled product however, this becomes more complex when you have several products and test fixtures that you have to maintain and program.  What we have found through experience in the lab is over the years we ended up with over a dozen different ISP programming cables because we just made them up as we needed them and the PCB layout was different for each test fixture we built. Since we did not assign a fixed set of ISP pins each cable was unique and only worked for one design.  We have since then set a standard connector and pin assignment for all CPLD and FPGA designs as we will present.  

Each manufacturer has their own pin assignments for programming their chips with a JTAG or serial protocol that easily translates down to a simple interface connector.  For the JTAG protocol that handles the majority of chips we selected a standard micro six pin connector with a 0603 four resistor isolated SMT for the required pull-up/pull-down terminations.  There are a couple of manufactures that offer the mating connector in a ready made cable that may be plugged into the programming ITF to the UUT.  Considering that the market is now thinning out through M&As this will make it easier to standardize on some interface configurations.  There are other programming modes designed into these devices as well which are used for more complex designs for testing boundaries and other elements within the FPGAs that are not covered in this part of the series since we will not be using any of them.  We will put on the table for discussion creating a new blog series to address FPGAs in the future. The JTAG protocol In-System Programming consists of four signals with the two resource pins which are shown in Table 17.0 below.

We have two types of connectors one for the ITF and one for the production product.  Generally our client selects the programming connector for the production unit that conforms to their in-house connectivity.  For the ITF we selected the standard SATA 7 pin connector since the cables are easily available and the connectors are fairly rugged for many inserts and removals as well as being cost effected, right angle connectors make it easier to interconnect as well.   Using the SATA connectors does change the Standard table assignments that is in Part 17, Table 17.0 which we show the changes in Table 18.0 below Pin Assignment Change in light cyan color and Table 18.1 for all the ISP programmers interconnect assignments.  This is also a change for us in the lab at BASIL Networks as well to upgrade our test system.  We still have the older system to service any obsolete equipment that our clients may still use since some of the Mil Spec requirements require maintainability for 10 years.

For production release ISP connectors, care should to be taken into consideration during the selection process.  The mating connector will be inserted and removed many times, once average for each programming instance.  The ISP connector on the product will see minimum insertion and extraction, however the mating connector will see heavy use.  The ISP connector on the PCB should have an alignment shroud to insure proper alignment during insertion.  We have used Samtec 6, 8 and 10 pin 1.27mm (0.050") pitch shrouded male connectors on the product PCB depending on the type IC's being programmed.  Female header cables are easily purchased through Samtec for a variety of lengths.  The male connector is a better choice for the PCB mainly due to the fact that the female mating header is comparable with flat cable and easily created.

Table 18.0  CPLD  ISP Standard Pin Assignment for ITF Cable Using SATA Connectors

For all PoD assemblies that will see heavy use of the ISP connector we updated the table for the selected SATA 7 pin connector and is shown in Table 18.1 below.

Table 18.1   Manufacture ISP Standard Pin Assignment for ITF SATA Cable Pin Assignment

OK, what we find the majority of the time is that the functional block diagram is not the schematic, it is a guide to develop the schematic.  The functional block diagrams purpose is to present an overview of how this device will function.  The schematic irons out the details for actually building a PCB.  

Some additional functionality has been added to the ISP interface which allows the ITF to turn on the ISP connector and well as determine if there is power to the Device being programmed.  This requires an additional Enable and Sense line for each IPS programmer adding an additional 10 CPLD pins to the ITF.  OK so we see how fast pins add up when we start to design.  We already experienced this when designing the AD-CHAN interface with only a single pin to spare and we still have a few functions for the AD-CHAN to address when we get back to the AD-CHAN PoD.  This is another reason the IPD System tracking of multiple projects - yeh, yeh I know, is there a caboose to the documentation train?

The next step is the isolation of the JTAG signal paths which consists of three inputs and one output from Table 18.0.  Generally the JTAG clock rate is dependent on the devices being programmed or tested., however, the clock has a range of 10MHz to 100MHz (100ns to 10ns per bit) and for most CPLD it is 10MHz nominal.  The digital isolation IC we selected is the Analog Devices ADUM241E1WBRWZ  for the 4 channel [3-out/1-in], the single channel isolation IC is the Analog Devices ADUM110N0BRZ both incorporate transformer (3000 volt) isolation methodology

We have a choice of using the UUT power through the ITF ISP connector or adding a separate isolated power supply for the UUT.  It is a good practice to use a separate isolated power supply for the UUT and a separate isolated power supply for the ITF ISP and just use the UUT power to signal the ITF that there is power top the UUT.  The total power for the Isolation side of the ITF ISP is less than 40MA per connector and the ribbon cable short distance less than 24" should work fine.  We are able to get the SN74AHC125N  Tri-state quad buffer in a real DIP package for a standard 14 Pin socket.  This allows for easy repair if the UUT fails.

Figure 18.0a is the updated functional block diagram for a single ISP with the added pins for control.  This will be repeated five times for all the ISP manufacturers we have selected.  For the followers you can change the ISP connector to a manufacturer that is not on the current selection or just make an interface cable to any one of the five ISP channels.

Figure 18.0a   Single Isolated ISP Programmer Interface

Figure 18.0b below shows the schematic of a single channel isolated ISP interface.

OK, some circuit details.  We selected a standard 5 volt supply to handle all the power both non-isolated and isolated.  The isolation takes place, obviously ion the Isolator IC's and when we add that extra enable bit we only needed a single isolator for this.  We also selected to use a separate single isolator IC to separate the JTAG lines from the control lines.  The power sense for the Isolated side is a standard optical isolator that only requires about 10ma at 3.3 volts to activate the output transistor.

The isolators U1 [4 channel] and U3 [single channel] isolate the manufacturers ISP device from the PoD being tested.  The single channel design is repeated with different IPS connectors for the manufacturers selected for this design. The multiple channels allow a single common ground for different manufacturer CPLD's while separating them for the manufacturers ISP to eliminate any interference while testing the PoD device.

The JTAG Standard Terminators RN1 and RN2 are required for both sides of the ISP translator.  When we disable the buffer U2 [74AHC125N] on the isolated side we want be able to set a known steady state for the CPLD device so we may test the PoD without interference from the ISP.

The isolated DC to DC step down 5Vdc to 3.3Vdc, PWR1 has isolation of 1200 Volts and is standard. There are more expensive ones that have 5000 volt isolation breakdown however, 1200V is adequate for our application.

The non-isolated DC-DC step down  5Vdc to 3.3Vdc, PWR6  is a standard buck converter and is available from many sources.

Figure 18.0b   Single Isolated ISP Programmer Interface

The full 5 channel schematic is shown in Figure 18.1 below which we laid out on a double sided PCB 3.9" x 7.0" that we use as a standard in the lab for the majority of our test interfaces.  We use a standard 4"x*'x1.5" standard plastic case for many of our designs when presenting Proof of Design developments.  The design was created using OrCAD capture and layout.

Figure 18.1   Schematic Diagram of the Isolated ISP Programmer Interface

The Layout is very basic and straight forward.  Since all the paths are signal data paths the maximum current for each channel is less than 80ma we do not nee a power and ground plane.  The PCB layout consists of 8mil trace/8mil space for all signal lines and 50mil trace for all power line traces.  8 mil trace / 8 mil space are easily manufactured with a 100% yield.

Figures 18.2, 18.3, 18.4 and 18.5 are the PCB Assembly, Top, Bottom Etch and Fab drawings respectively for the prototype build.

Figure 18.2   ITF ISP  PCB Assembly Layout

Figure 18.3   ITF ISP  PCB TOP Etch Layout

Figure 18.4   ITF ISP  PCB BOTTOM Etch Layout

Figure 18.5    ITF ISP  PCB FAB Drawing

OK,  this is the first part of the ITF design.  It is a bit too early in the program to make this available to the readers since a prototype has not been built yet.  This part of the ITF design is not a complex layout however, there were times even on the simplest layout errors were made, it is the nature of the beast.  As a rule I do not use the auto routing features in the layout designs.  I prefer to perform the layout by hand using a fixed grid pattern and setting the trace/space parameters to a fixed number.

It is easy to see how product development gets complicated when you bring up testing and Proof of Design.  What makes this interesting for small companies with limited physical resources is the number of hats that each individual is expected to wear to contribute to the companies growth as well as individual growth.  Small companies are a great training ground for engineers and entrepreneurs' and if the company takes off you will obviously see the results of your efforts directly, there will be more opportunities to grow.

The raw material cost for the PCB build:
Creating the Bill of Material (BOM), we use to call this the parts list  The Schematic capture program that is used for this presentation is OrCAD since we are most comfortable with it and have invested heavily in libraries for such.  There are pros's and con's for all of the design packages on the market today.  Some packages allow the full library for components and inventory control, some just give you a schematic name and footprint space and everything in between.  Over the years we developed a method to handle all BOM's for each project and a database library for them that we use for RoHS documents.  What we do also is insure that the data sheet for components used for the design stay with the design at the current revision level for reference.  Since the Internet is constantly changing and documents are added and deleted it is not recommended that the Internet be used as a link to older documents especially if the company is acquired or closed.

So for our approach we actually use a spreadsheet for this since there are both paid licenses and free spreadsheet applications on the Internet, we have used both MS Office and LibreOffice packages and they both work fine and are interchangeable.  Table 18.2 below is our spreadsheet that we use here for the majority of our designs and contains the following columns.  These spreadsheets are saved with the project using the BASIL Networks IPD system that we discussed previously.

Table 18.2   Common BOM Spreadsheet Column Names

The spreadsheet example Figure 18.6 shown below gives a good picture for management, engineering and manufacturing or any contract manufacturing house selected.

Figure 18.6   ITF   ISP Isolation Interface BOM Spreadsheet

How to Obtain a Finished ISP ITF section:
Our plans when the IoT Core Platform presentation is finished is to offer a finished ITF and the IoT Core Platform to the public that has many more features than the ones being developed for this presentation.  We already have completed two different PoD products that are being reviewed for manufacturing release and we are offering custom development for contract manufacturing companies as well as the entrepreneur small company that want to setup a development test base for present and future development contracts that they are awarded.  Please use the BASIL Networks Contact Form to be put on a mailing list when we are ready to supply the manufacturing prints or if you are interested in purchasing the entire system as a Plug'N'Play.

SUMMARY:
The question "why do you want to isolate the ISP device from the manufacturer for the CPLD being programmed?" This question is asked several times and is always a valid question to ask.  The answer that we give here in the lab is from our experiences programming FPGA's and CPLD from different manufacturers and of course the errors that seem to arise during development, we have had our share of destroying ISP devices.  Yah, Yah--- we are experts or at the least well seasoned professionals and those "oops" still happen, it is called human.  In our experience it is very easy to pop an ISP device with the wrong voltages or incorrect hookup or a short on the board that zaps the ISP device.  Isolation allows the repair of the isolated output and protects the ISP from the manufacturer as well as being very cost effective.

The other question that was asked several times, is it possible to program the CPLD JTAG connections with an alternative programmer?  The simple answer is yes,there are programmers that allow programming several manufacturers devices other than the manufacturers ISP device.  The complicated answer is why would you want to when the CPLD, FPGA manufacturer gives you an ISP device programmer and software designed for their chips?  It is not only time saving but advantageous to use a manufacturers ISP device for validation since the validation of the device has already been proven reliable.  Added to the answer is each manufacturer has their own coding ID for each chip being programmed along with variations in the security bits to lock the device.

The direction of this blog has been developing from the conception and the direction has taken a few turns, however the objective is still the same, to develop an IoT Core Platform.  The directions are apparent that this is an educational blog and the end result is that we will offer the product to the public to continue on with several applications development projects that will encourage entrepreneur's to innovate and apply the knowledge taught here to develop new products on their own.

BASIL Networks will be developing educational class room video modules to discuss engineering and project management principles by active example with hardware, software and lab experiments as we continue on with the series.  All hardware and software designed during this series will be available through our on-line video tutorials along with the class materials.  Figures 18.0 through 18.5 are an example of the product design tutorials that will be presented as the IoT Platform series moves forward.  It is not advised to copy these presented designs since the finished product will be tested, validated and available as we complete each sections PoD.

As the series progresses the author, Sal Tuzzo will be available for discussion through the BASIL Networks Contact Form for those that want to apply this series to conduct their own experiments.  I will always be appreciative for the private comments sent through the contact form for suggestions and advice during the development of this series.  This is a growing opportunity for everyone entering into product development as well as a great review for us "well seasoned" in the field to just refresh our DRAM.

It is recommended for those that have specific questions to use the BASIL Networks Contact Form for questions to separate them from getting lost in the general comments for each blog presentation.  For all specific design request or contracts please feel free to contact us.

Part 19+ Preliminary Outline" A/D Channel Hardware/Software Design and the ITF: -Continued

• Reviewing the IPD Documentation System
• Creating the Schematic for the ITF
• Creating the PCB Layout for the ITF
• PCB FAB drawings and ordering the ITF for this series.
• A link to download the IBPD System for this series.
• A review or the Successive Approximation algorithm used in A/D conversion
• Testing the A/D peripheral.
• Adding other features to the A/D Channel while finishing the PoD schematics for the ITF
• And more ....

Reference Links for Part 17:

ITF Selected Components

• Analog Devices ADUM241E1WBRWZ  3/1 Isolation Configuration
• Analog Devices ADuM240E0BRWZ  4/0 Isolation Configuration
• Analog Devices ADUM110N0BRZ Single Channel Isolation
• Standard SN74AHC125N
• Memory 1024x16 10ns IS61WV102416DBLL-10TLI
• Memory 2048x16 10ns IS61WV204816BLL-10TLI
• PCB Termination Blocks PTSA Series

BOM Spreadsheet and Component datasheets ZIP file

PGA281 Programmable gain Amplifier Datasheet
IS66WVE4M16EBLL 64Mbit (4M x16) Pseudo SRAM Datasheet
Alliance Memory AS1C8M16PL 128Mbit (8Meg x16) Pseudo SRAM

Intel®/Altera® Quartus Download 9.1 sp2 from Archives
Intel®/Altera® Quartus Lite 18.x Download

Requirements Traceability Matrix  (RTM)
Project Management
Mezzanine Board

The majority of Internet scheme and protocol information are from a few open public information sources on the net, IETF (Internet Engineering Task Force) RFC's that explain details on the application of the protocols used for both IPv4 and IPv6 as well as experimental protocols for the next generation Internet and the Network Sorcery web site.  The remaining of this series on the IoT platform will be from BASIL Networks MDM (Modular Design Methodology) applied with the Socratic teaching method.   Thank You - expand your horizon- Sal Tuzzo

Network Sorcery: http://www.networksorcery.com
The Internet Engineering task Force: IETF - RFC references
Wikipedia https://en.wikipedia.org/wiki/Main_Page

Memory Segmentation
The Memory Management Unit (MMU)
Virtual Address Space
Virtual Addresses and Page Tables
Extended Memory

Part 1  Introduction - Setting the Atmosphere for the Series (September 26, 2016)
Part 2  IPv4, IPv6 - The Ins and Outs of IP Internet Addressing (November 11, 2016)
Part 3  IPv4, IPv6 DHCP, SLAAC and Private Networks - The Automatic Assignment of IP Addressing (November 24, 2016)
Part 4  Network Protocols - Network, Transport & Application (January 10, 2017)
Part 5  Network Protocols - Network, Transport & Application Continued (Aug 17, 2017)
Part 6  Network Protocols - Network, Transport & Application Continued-The Ethernet Protocol(s) (Sept 21, 2017)
Part 7  Network Protocols - Network, Transport & Application Continued-The CRC-32 and Checksums (Nov 27, 2017)
Part 8  IoT Core Platform& Development - Embedded Processor Systems-(SoC)-(SIP) Core Processor -Embedded System Configurations  (Jan 12, 2018)
Part 9  IoT Core Platform Development - Embedded Processor Systems-(SoC)-(SIP) Core Processor -Embedded System Configurations (Mar 16, 2018)
Part 10 IoT Core Platform - SoC Core Processor of Embedded Systems-Product Development Management (May 5, 2018)
Part 11 IoT Core Platform - SoC Core Processor of Embedded Systems -Documentation Management Processes (June 27, 2018)
Part 12 IoT Core Platform - IoT Core Platform - Product Design  -Creating Conceptual Design Documentation (July 29, 2018)
Part 13 IoT Core Platform - Peripheral Interface Devices  -Peripheral Design From the Beginning (Oct 7, 2018)
Part 14 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design (Oct 29, 2018)
Part 15 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design-Continued (Dec 7, 2018)
Part 16 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design-Continued (Feb 11, 2019)
Part 17 IoT Core Platform - Peripheral I/O Development - Peripheral Device Real World Testing -Continued(Mar 15, 2019)

Publishing this series on a website or reprinting is authorized by displaying the following, including the hyperlink to BASIL Networks, PLLC either at the beginning or end of each part.
BASIL Networks, PLLC - Internet of Things (IoT) -Security, Privacy, Safety-The Information Playground Part-17 Peripheral I/O Design - Peripheral Devices- Real World Testing - (Mar 15, 2019)

For Website Link cut and paste this code:

Part 17: IoT Core Platform Development;- Peripheral I/O Device Design
The IoT Embedded Core Platform -Peripheral Devices Real World Testing - Continued

"You cannot change your destination overnight, but you can change your direction overnight"   John Rohn (Sept 17, 1930  - Dec 5th, 2009)

Part 1 Introduction - Setting the Atmosphere for the Series (September 26, 2016)
Part 2 IPv4, IPv6 - The Ins and Outs of IP Internet Addressing  (November 11, 2016)
Part 3 IPv4, IPv6 DHCP, SLAAC and Private Networks - The Automatic Assignment of IP Addressing  (November 24, 2016)
Part 4 Network Protocols - Network, Transport & Application (January 10, 2017)
Part 5 Network Protocols - Network, Transport & Application -Continued (Aug 17, 2017)
Part 6 Network Protocols - Network, Transport & Application -Continued -Ethernet Protocol (Sept 21, 2017)
Part 7 Network Protocols - Network, Transport & Application -Continued -The CRC-32 and Checksums(Nov 23, 2017)
Part 8 IoT Core Platform - SoC Core Processor of Embedded Systems (Jan 12, 2018)
Part 9 IoT Core Platform - SoC Core Processor of Embedded Systems-Vulnerabilities (Mar 16, 2018)
Part 10 IoT Core Platform - SoC Core Processor of Embedded Systems-Product Development Management (Apr 5, 2018)
Part 11 IoT Core Platform - SoC Core Processor of Embedded Systems -Documentation Management Processes (June 27, 2018)
Part 12 IoT Core Platform - IoT Core Platform - Peripherals -Documentation Management Processes (July 29, 2018)
Part 13 IoT Core Platform - Peripheral Interface Devices  -Peripheral Design From the Beginning  (Oct 7, 2018)
Part 14 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design (Oct 29, 2018)
Part 15 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design-Continued (Dec 7, 2018)
Part 16 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design-Continued (Feb 11, 2019)
Part 18 IoT Core Platform - Peripheral I/O Development - Peripheral Device Real World Testing -Continued(Apr 25, 2019)

Quick review to set the atmosphere for Part 17:
From the previous Internet of Things Part-1 through Part- 16 have brought us to this level of what we want in an IoT core Platform.  It has also brought us awareness of the needs for privacy, security and control of devices attached to the Internet and how easy it is to intercept various protocols and change data being transferred over the information highway.  From all the data breaches being published on a daily basis we see that the original design of the Internet still has a couple of shortcommings from conception.  One shortcomming is .... wait for it ....security!  We will be designing security into the IoT Platform from the start and not as an after thought to be added later.

Now that the basic idea and some of the different aspects of product development have been introduced, it is a good practice to document ideas and concepts as well as additions using the IPD system.  Using the RTM section to insure that as we develop each section there are guidelines and test cases to insure that all the pieces fit together.  The basic features incorporated into the IPD system are:

• Compartmentalization - for different categories of documents of development stages, Business, Technical, Financial etc.
• Organization - Project level single Top-Level-Directory structure separates projects.
• Traceability - Bidirectional trace capabilities of the development processes, test cases and validation.
• Security - Incorporates Compartmentalization security practices for controlled access of project directories and files.
• Backup/Restore - Archive processes to insure all the required files and directories are included archived from the Top-Level-Directory.

Technology has advanced at a rapid rate over the past 50 years that it becomes difficult to keep up with the technology, however what is interesting is that the level of  "common knowledge" has also increased from the use of the technological advancements.  This series is presenting some of the advancements that are now considered common knowledge in the society and to our series as we all do with common knowledge, without a second thought and us this common knowledge to explore other areas of interest and repeat the process.   Our intent is to make the peripherals interfacing common knowledge to be easily applied to any core processor and perform functions to experiment and collect data to advance science.

What we want to cover in Part 17:
In Part-16 we presented that  fact that we should address testing of the peripherals (Proof of Design) PoD with a prototype build to insure when we interconnect several of the peripherals the throughput required for the applications will be met.  This also put us in a position to change the development direction from the peripheral that we have to developing a test methodology that will be used for testing the remaining peripherals for the platform.  With that stated we will move forward with detailing the Interface Test Fixture (ITF), creating a schematic and PCB layout for the ITF, not all in this part though since it is a relatively large development.

Creating a new IPD project for the Interface Test Fixture to keep track of the development process. Good golly Miss Molly will the documentation ever end?  Maybe in the tinker toy lab, but not for a real product development!  Developing good engineering documentation habits comes with the territory, documentation is still in the picture and still important.

Setting up Requirements Traceability Matrix (RTM) for the test cases for the analog input.  Traceability during development covers all aspects from Business, Legal as well as Technical and is essential when validating each stage of the project.  We will keep this more at a technical project development, PoD (Proof of Design) level for a while until we get to a point where the business side is required.

OK, we will not be able to cover all the following sections in a single presentation/part so we will break this down and present the ITF development in a few sequential parts for the series. Just a short change in direction, however a better validation to complete the objective.

Expanding on the ITF functional block diagram Figure 16.1 the following sections documentation will be created to incorporate into the Interactive Product Development System.  

• The CPLD, FPGA In Circuit Programming Model
• The Isolation Interface - Pros and Cons
• The BUS Interface and Control
• The BUS Expansion
• The Peripheral PoD Common Interface Architecture
• The ITF On-Board Memory Configuration
• The ITF Serial Interface Group  I2C, SPI
• The ITF Computer Interface Model
• The ITF to PoD Device Physical Interconnects
• SUMMARY

Lets Get Started:
The IPD Documentation - Developing Documentation Discipline
Remember changing direction overnight does not mean changing goals or the final destination, it is just a better way to insure you will reach them.  In my years of exposure to the design arena as a designer and mentor I have had the honor of experiencing innovative and passionate creators to realize that the thought process of creative passion is not a linear step function, 1, 2, 3 ...N, probably because humans are not robots, that follow a preprogrammed set of processes as some may think.  The innovation of the human mind subconsciously is always performing scenarios to find the best solution for the task at hand.

OK, when we were discussing this project the question came up, Why did you select to use two CPLDs in stead of just on FPGA?  These are the results of that discussion, to review what was stated earlier.  The first reason is we selected MAX line of CPLDs was purely out of the experience level over the years we have used them.  The second reason we selected Intel®/Altera® is the way Altera archives the older revisions of  software on their website, both by date, revision number and the chips supported.  Another factor that weighted it was the amount of resources required to use the latest release of the software of all CPLD/FPGA manufacturers.  

Inrtel/Altera new release with a 12GB local DRAM would not compile the AD-CHAN  MAX-II CPLD and ran out of memory for the timing diagrams.  All the older releases run on 8GB DRAM/4GB DRAM on the x32 systems easily while the latest release states up to 32GB DRAM or more.  

This would require the majority of small companies and entrepreneurs to purchase the latest and greatest motherboards that supports that amount of memory.  The majority of older desktop motherboards are limited to 16GB including the Graphics memory and many of the laptops are limited to 8GB that are only a couple of years old.  Another deciding point of using two CPLDs you double the number of I/O pins that should cover this ITF design easily and have some logic Elements to spare for feature expansion and design changes.

OK, a quick review of the documentation system we will be using, Yes again, Ok I'm sounding like management now, - so what does that all mean to this series?  This means that to assist this innovative development process that may change direction at times from one development task to another a tracking system should meet the following requirements.

1. Interactive - by second nature without thought
2. Flexibility - being able to record changes and additions in real time.  During development changes in one project can easily effect another project.
3. Multiple Project Tracking - This is where we are now - being able to start and track new projects that will eventually interact with the product development at hand, hence: the IoT Core Platform development project.
   So, lets give the ITF a Project name- Universal_Peripheral_ITF for lack of a better one.

Repetition is the mother of retention,  wait a minute!..., I think I read that somewhere before.

CPLD, FPGA In Circuit Programming Model:
Since we are using CPLDs only on this ITF design we will start at the In-System-Programming (ISP) configuration.  This looks like and generally is a simple connection to program a CPLD on an assembled product however, this becomes more complex when you have several products and test fixtures that you have to maintain and program.  What we have found through experience in the lab is over the years we ended up with over a dozen different ISP programming cables because we just made them up as we needed them and the PCB layout was different for each test fixture we built. Since we did not assign a fixed set of ISP pins each cable was unique and only worked for one design.  We have since then set a standard connector and pin assignment for all CPLD and FPGA designs as we will present.  

Each manufacturer has their own pin assignments for programming their chips with a JTAG or serial protocol that easily translates down to a simple interface connector.  For the JTAG protocol that handles the majority of chips we selected a standard micro six pin connector with a 0603 four resistor isolated SMT for the required pull-up/pull-down terminations.  There are a couple of manufactures that offer the mating connector in a ready made cable that may be plugged into the programming ITF to the UUT.  

Considering that the market is now thinning out through M&As this will make it easier to standardize on some interface configurations.  There are other programming modes designed into these devices as well which are used for more complex designs for testing boundaries and other elements within the FPGAs that are not covered in this part of the series since we will not be using any of them.  We will put on the table for discussion creating a new blog series to address FPGAs in the future.

The JTAG protocol In-System Programming consists of four signals with the two resource pins which are shown in Table 17.0 below.  The connector used in the lab is a 1.27 mm (50 mil) center dual row 2x3, 6 pin standard connector. The manufacture numbers are Amphenol 20021321, Samtec FLE-103-01-G-DV-K to name a couple.  Any connector type will work, however we picked the 1.27mm pitch for the size that seems to take up the least room and easily available from several sources and the cables are easily created even in the lab.

Table 17.0  CPLD  ISP Standard Pin Assignment for ITF Cable

Over the last few years, M&As have narrowed the major players in the Programmable Logic Device arena to Intel/Altera, Xilinx Inc., Cypress Semiconductor Corp., Lattice Semiconductor Corp.,  Microchip/Atmel for the higher visibility ones.  We will look at each of the programming configurations from these manufacturers programmers for the standard JTAG In-System-Programming protocol configurations and apply the individual connectors out to a standard interface translation cable.  All the above mentioned programmers have standard connectors that are available from several sources so the translation from the individual ISP programmers will not be an issue.   

We will place the standard connectors on the ITF main board and trace them out to specific programmer connector.  Since this is a "universal ITF" making it compatible to test other peripherals that incorporate different CPLD and FPGA devices from different manufacturers we will add the universal interface to address different types of JTAG programmable logic on the same UUT.  This will maintain a single ISP cable set for all the different manufactures and make designing these devices into the product more organized.  With the incorporation of the IPD system organizing and tracking all the different manufacturers becomes easier as we will experience.  Table 17.1 shows the pin assignments for each manufacturers JTAG programmer pin assignments allowing a single translator cable to program the CPLD/FPGA and how the PCB traces interconnects to the translation cable for each manufacture.

Table 17.1   Manufacture ISP Standard Pin Assignment for ITF Cable Pin Assignment

The next step is the isolation of the JTAG signal paths which are three inputs and one output from Table 17.0.  Generally the JTAG clock rate is dependent on the devices being programmed or tested., however, the clock has a range of 10MHz to 100MHz (100ns to 10ns per bit) and for most CPLD it is 10MHz nominal.  The digital isolation IC we selected is the Analog Devices ADUM241E1WBRWZ  which incorporates a transformer isolation methodology.  

We have a choice of using the UUT power through the ITF ISP connector or adding a separate isolated power supply for the UUT.  It is a good practice to use a separate isolated power supply for the UUT and use the UUT power for the isolated ISP through the ITF ISP connector.  The total power for the Isolation side of the ITF ISP is less than 40MA per connector and the ribbon cable short distance less than 24" should work fine.  We are able to get the SN74AHC125N  Tristate quad buffer in a real DIP package for a standard 14 Pin socket.  This allows for easy repair if the UUT fails.  Figure 17.0 shows the functional block diagram of the ISP section of the Interface Test Fixture.

Figure 17.1   Functional Block Diagram of the ISP section of the ITF

The control of the drivers should be isolated as well in order to insure a known off state for the UUT.  The discussion of remote CPLD code updates will be discussed during the security section since the CPLD programming functionality is already on-board it is just not connected to the UUT CPLD/FPGA.  

Some questions arise as to why we just use one ITF ISP connector for all the manufacturers and just interconnect the ISP connectors from each programmer?  Well, for us here at BASIL Networks our clients give us their preferred list of components including which programmable logic IC to use that they already stock, so as a policy we always look at ITF's as universal as to accommodate our clients.  The PCB layout for this section of the interface will take up a bit of PCB real estate, 8 connectors, 9 chips.  What we use here is a standard 4" x 7" PCB footprint for these interfaces that fits easily into a 4.5" x 8 x 1.5" enclosure either plastic or metal that gives a good size/function optimization for ITF devices.  We will cover this when we get tot he PCB Layout of the ITF.

The Isolation Interface Pros and Cons:

Manager:  We don't need isolation!
Engineer: Yes we do- period.
Manager - Convince me the we do.

OK, Why do we want or need and Isolated I/O interface on the Interface Test Fixture anyway?  Good question! and needs to be answered since we just went ahead incorporated isolation for the In-System-Programming Model above, so lets explain why.  The general consensus for custom test equipment development is to add isolation if possible to protect the ITF when the device under test fails or goes into self destruct mode at power-on.

Ok, so what about this case were it is all low voltage, 3.3Vdc and 5Vdc as well as low current?  Why not just go right into the CPLD interface?  Yes, we actually could go right into the ITFs CPLD, however if a failure happens that overdrives or shorts the UUT devices inputs / outputs that causes the ITF CPLD to fail then we have to replace the ITF CPLD.  You will only be able to replace SMT components a few of times before you have to replace the ITF.  

For the ISP programmers, the isolation chips are DIP socketed, yes, they still make DIP sockets that are throughhole and actual DIP packages to.  See, even some of the "old"/seasoned technology still has a place in the modern technology world.  So for the manufacturers ISP chip programmers it is recommended since we are also translating the signal paths to a common pin assignment for the JTAG programming interface.  Lets lisst the Pros and Cons for the case of isolation.

The Pros for Isolation -

• Test equipment protection from the UUT is the first consideration when setting up any test fixture.
• Noise and ground current elimination - There are times when the test equipment will add noise or other signal return paths that can fail or even pass the test process.  Isolation separates the UUT from any stray signals that may find it way to the UUT and compromise the test data being collected.
• For the Control lines it is always a good practice to isolate them.  The isolated control lines will balance out the delays with the data lines as well.

The Cons for Isolation -

• The first is data throughput speed.- Isolation generally incorporate delays which may compromise that actual throughput when the system UUT is attached to the actual application.
• The next con is balancing the control lines with the data lines to insure the simulation of the BUS will accurately emulate the CPU that controls the BUS  peripheral BUS.  This is one area that can cause software programmers a real headache if the BUS data and control lines are not synchronized properly.
• I/O voltage compliance - Insuring that the I/O of the UUT comply with the I/O of the ITF in order to insure data transfer integrity.  The selection of the I/O isolation chips are the key to proper I/O voltage translation.

Isolation Summary:
Ok, so are we going to design in Isolation? - the answer is yes.  Why?- well, for one this is a universal ITF and the IoT platform will be just one of the devices it is applied to.  One of the main reasons is this is an on-going educational series and we have the time to address many peripheral applications;  designing this for only one would be a short sighted design.  

So, we see from this ITF example of how a simple test fixture easily explodes into the universal ITF and adds more time and cost to the development schedule that was not anticipated at the beginning.  Another aspect is that since this is a separate project within the IPD system it would be easily updated as required for other applications and it will give us a real world experience through a some of the challenges faced during a development project.  

Moving forward to the actual design of the ITF we want to keep thigs as simple as required to address the tasks to be performed..  This is where risk management attempts to sway the technical group to change direction.  We will cover the isolation of the remaining section of the ITF as we address each of the sections.  There are many that think risk management is a PITA, however in reality if presented financially unbiased for the best quality of a product it is a great checks and balance mechanism. OK you may laugh, the author cannot see you or hear you, unless you put it in a comment.

BUS Interface Control:
The BUS control is an important part of the ITF for several reasons, one of which is that it will include some serial transfer protocols that we will also use for the peripherals for the IoT Platform.  Since we already have a 50 Mbps SPI interface on the A/D Channel design adding this to the control section is a cut and paste operation for the CPLD used in the ITF and we will look at higher speeds as well.

Figure 17.2 shows the Data I/O and Control portion of the ITF, initially we suggested a 32 bit BUS I/O, however since we decided to incorporate isolation the real estate of the PCB required increased which forced us to drop back to a 16 bit interface. The Isolation IC we selected comes in a few configurations that fit the remaining sections as well and is a four bit chip.  This yields 14 ICs for the isolation, three octal transceivers for the data and control for a 16 bit Data I/O and 8 Lines Control for the ITF.  

This brings up the question do we really need a 32 bit I/O bus?  From my experiments with 32 vs 64 bit Linux and windows, the speed differential is only a few percent faster and x64 bit does require more memory.  Since all virtual tasks in windows seem to follow under a 16 bit virtual environment when using Intel® processors a 16 bit environment seems to by in line.  We will perform some multi-processor, multi-task benchmarks for other processors after the series and if time is available, comments are welcome if anyone has already performed similar tasks.

Figure 17.2   Functional Block Diagram of the ITF Data I/O Section

The digital isolators are ADuM240E0BRWZ  four bits per chip and are SMT and may be put directly on the board since they are buffered by a bus transceiver chip as well.  The octal buffers use are industry standard SN74HC540N and available in real PDIP packages for use with sockets, several distributors stock these octal transceivers since they are commonly used in test equipment.  So as we see here adding isolation does add a few components to the ITF design.

The critical interface control of the ITF is the synchronization of the BUS and I/O strobe control lines.  Many of the embedded systems use software strobes that add delays that vary with the CPU clock speed used.  This is one of the reasons we will be looking at a hardware control interface for data I/O in order to use a variety of CPU's with various speeds.  Just the typical reasoning used to build a universal ITF with a hardware BUS interface structure.  

Risk Management -  The one issue that will always exists when test fixtures or test equipment enters the picture is that of risk management and the push to spend the least amount of money and resources on test instrumentation.  "Do not test now, redesign later"; over the years in product development we have experienced risk managements decision to forgo the test fixtures and go right to a manufacture build that ended up in costing the company an order of magnitude more than the actual products development costs due to having to redesign the product.  It is not uncommon even today with the new generation of risk management and the so-called "automatic test simulation and verification technology", all the more reason to proceed carefully.  One fact to keep in mind is that the test equipment may be used for other development or simply stay with the product manufacturing for the life of the product.  We have always found it less expensive and more reliable to build the test equipment for the product during development.

BUS Expansion:
The BUS Expansion is used for external devices for testing that are generally not part of the IoT Platform.  This would be another ITF device for special testing and data collection such as a special temperature cycle mechanism for testing over temperature while operating or a peripheral that requires external triggers to start the operation.  The Expansion BUS may also be used as a peripheral test status register.  It is an eight bit bi-directional bus that may be programmed at the bit by bit level.  Figure 17.3 below show the functional block diagram of the expansion section.

Figure 17.3   Functional Block Diagram of the ITF Expansion Section

Peripheral PoD Common Interface Architecture:
As we see the 16 bit Proof of Design interface has already lead us to a common interface bus architecture at least for the AD-CHAN peripheral.  However we are not limited to only one I/O architecture, this would depend on the peripheral we interface and if we use more than one CPU;  the CPU memory architecture incorporates a parallel architecture for instruction speed and memory management.  From our experience the trade off from a 32 to 16 bit I/O architecture is small and the 16 bit architecture is considered the "sweet spot" of peripherals for parallel I/O interfaces.

If we really need more speed then we can always turn to PCI-Express, however that does require FPGA support and in reality, it is just a parallel to serial to parallel type architecture that also has other inherent delays that are present in the PCI architecture.  The ideal is a direct parallel architecture which is a memory cycle pipeline transfer when using the I/O peripheral as a memory mapped I/O.  We will experience this when we move into testing the AD-CHAN peripherals on board memory which is similar.  The expansion part of the ITF emulates an extended memory address so we will be able to incorporate blocks of memory as a particular application may require. This opens the array of applications that the IoT Core Platform may address.

ITF On-Board Memory Configuration:
The ITF On-Board memory function is a nice function to have to test many data throughput conditions, however it is not an absolute requirement except for this series.  Since this is an educational series we will add it as a separate function on the ITF and synchronize it with the main Data I/O and Control Bus CPLD.  

High speed SRAM in the 10ns arena are easily available in the 1 Meg x16 bit single chip.  When you go to 2Meg or 4Meg x16 the price obviously increases but if you have the room on the board it may be better to just add the extra chips footprint to the PCB and add it as needed.  For testing A/D converters of 16 bits and under a 1 Megx16 is more than adequate and we will address this as we get to that section of the series.  Figure 17.4 below shows the CPLD and SRAM functional block diagram where the SRAM connects directly to the CPLD and does not require any buffers.   The memory IC we selected is IS61WV102416DBLL-10TLI 1Megx16 or the IS61WV204816BLL-10TLI  2Megx16 and are available from several distributors.

Figure 17.4   Functional Block Diagram of the ITF On Board Memory

ITF Serial Interface Group - I2C, SPI
The Serial I/O group consists of some basic I²C, SPI and QSPI interfaces that are not integrated into the ITF design mainly because they will be a separate USB interface in a separate fixture.  These interfaces are already integrated into the IBPD test system as part of the basic I/O modules.  We will cover those devices later in the series as we need them.

A brief overview of the use for each of these devices when developing the IoT Platform I/O are listed below. Data about these interfaces are saturated on the Internet and we are not going to add to the saturation experience.

• SPI - Serial Peripheral Interface - As we presented the A/D Converter incorporated a high speed serial interface that follows the SPI architecture
• I²C - Inter IC Bus - Many peripherals today especially some of the complex functions use I²C or SPI or similar serial interfaces for control and data transfer.
• QSPI - Quad SPI - This is used most with FLASH memory and uses four data lines to transfer data and control.

ITF Computer Interface Model:
Now that we covered all the IoT Peripheral side of the hardware the remaining part if the ITF is how do we connect it to the desktop or laptop computer to control and collect data?   The Interface that will control the ITF that we will incorporate into the standard IBPD system specifically for this series is a USB 2.0 COTS controller for simple testing and interfacing.  BASIL Networks will modify the core IBPD system to incorporate the drivers specifically for this series and will be offered free to download for this series after the ITF presentation is complete for those that are experimenting while following the series.  Schematics, PCB Fab drawings and CPLD code will also be available.

The interface selected is a simple USB to 16 bit standard computer interface architecture that is connected to the Memory Access Controller CPLD which may change as we create the schematic and assign pins to each of the CPLDs.  As each peripheral is developed the IPBD software scripts will be presented for downloading to complete the development process.

We have searched the Internet for a simple USB to Parallel bridge IC and found that the FTDI USB bridge device seems to be the industrial standard and includes software for Windows, Linux. This will allow an easy parallel port interface as shown in Figure 17.5 below.

Figure 17.5   Functional Block Diagram of the ITF to USB 2.0 Bridge

ITF to PoD Device Physical Interconnects:
OK, one last item for the ITF that we have to cover before diving into creating the schematics.  Since we are building Proof of Design (PoD) for several of the peripherals for the IoT Platform we should decide on a standard interconnect platform so we can just Plug'N'Play these peripherals without have to create separate cables for each of them.

This is an important area to consider since what we select may limit other type peripherals for being connected.   The suggestion here is to design in as much flexibility as reasonable to connect other peripheral PoD devices.  The ITF manual connections type is single wire Push&Connect terminals and a secondary connection using Flat ribbon cable connectors.  Ribbon cables are press fit connectors which are easily assembled in the lab and offer many advantages for connecting several peripherals on a single cable for testing.

The PTSA Series connector series is what we use here in the lab allows the use of prototype breadboards for smaller circuits and experimentation as well before jumping into a full PCB layout.  Our intent here is to present a universal ITF device that will be useful for several years of experimentation and development of peripherals that are not internal in the embedded processor ICs.

This brings us to the presentation of the ITF hardware functionality, the next part is to create the schematics and layout of the ITF and prepare the PCB's for fabrication.  So as a quick review Figure 16.1 is shown below that combines all the previous sections of the ITF.  It is easy to see how and why test instrumentation is a high profile area for discussion.  It sometimes entails more complexity than the product design since it has to test the critical parts of the design that will be exercised the most during an application.  The key area of test instrumentation is to insure that the flexibility is incorporated during development and that the rights to the ITF belong to and controlled by the designer and manufacture to insure some type of security for prevent counterfeiting of the design.

Figure 16.1  ITF Test Setup Block Diagram

SUMMARY:
It is obvious now that ITF will take a few parts to complete prior to moving forward with the I/O Peripheral development as was intended from the beginning.  Putting the process in writing gives us a better perspective of how a project easily takes of on tangents that are required to complete the development.  For the implementation of the ITF to the IPD Documentation system, the conceptual documents contain Part-16 and Part-17 to begin the process.

The never ending roll test equipment plays in project development is a critical part of the product development success.  To test and validate a project like the IoT Platform and its peripherals takes a deeper understanding of the core of the product than just the applications.  A example, the Smartphone is used by many that have no idea nor do they require that knowledge to design, develop and test the phone, however they are very well versed in using the device integrating it into their everyday life.

As we stated throughout this series, product development has many sections for a successful development and it is now easy to understand why test equipment is a high profile subject matter.  The cost of test equipment to test a product may easily exceed the cost of the actual product development in time and resources and should be evaluated carefully.  

Test equipment development is a project within itself and should be done in parallel with the product development to insure all the test performance issues are addressed accurately.  Test equipment physical interconnects main function is to allow the capability and access to test all functions of a product and of course accurately collect data for performance analysis.

A product development project does require parallel development of the IoT Platform and the ITF however, incorporating the IBPD system methodology we should only have to design the initial ITF interconnectivity once to cover all the remaining peripherals which makes the ITF a universal test device that enters the reuse category.  And.... not to mention that the Interactive Product Development (IPD) System allows us to maintain organization of all documentation at an independent project level to run several projects simultaneously.  No fancy names or complex software gymnastics, just a simple effective, efficient tool to assist the designer(s) through product development stages.

There are still a few more sections for the Analog Input peripheral that has to be completed which we will cover in the next part of the series.  What we have been able to accomplish to date is a solid ground floor understanding of how the IoT peripheral devices that we would like to be configured as part of  the core CPU.  The selection of the Analog Input device is a good start to understand how peripherals are configured and controlled regardless of the type of BUS interface used to communicate with the host CPU.

Development is not a simple smooth road in a technology environment that is constantly changing and offering more flexibility and features introduced each year.  We have be able to address this rapidly and implement changes within a competitive time to market in order to obtain a market share.

As the series progresses the author, Sal Tuzzo will be available for discussion through the BASIL Networks Contact Form for those that want to apply this series to conduct their own experiments.  I will always be appreciative for the private comments sent through the contact form for suggestions and advice during the development of this series.  This is a growing opportunity for everyone entering into product development as well as a great review for us "well seasoned" in the field to just refresh our DRAM.

Part 18 Preliminary Outline" A/D Channel Hardware/Software Design and the ITF: -Continued

• Creating the Schematic for the ITF
• Creating the PCB Layout for the ITF
• PCB FAB drawings and ordering the ITF for this series.
• A link to download the IBPD System for this series.
• A review or the Successive Approximation algorithm used in A/D conversion
• Testing the A/D peripheral.
• Adding other features to the A/D Channel while finishing the PoD schematics for the ITF
• And more ....

Reference Links for Part 17:

ITF Selected Components

• Analog Devices ADUM241E1WBRWZ  3/1 configuration
• Analog Devices ADuM240E0BRWZ  4/0 Configuration
• Standard SN74AHC125N
• Memory 1024x16 10ns IS61WV102416DBLL-10TLI
• Memory 2048x16 10ns IS61WV204816BLL-10TLI
• PCB Termination Blocks PTSA Series

PGA281 Programmable gain Amplifier Datasheet
IS66WVE4M16EBLL 64Mbit (4M x16) Pseudo SRAM Datasheet
Alliance Memory AS1C8M16PL 128Mbit (8Meg x16) Pseudo SRAM

Intel®/Altera® Quartus Download 9.1 sp2 from Archives
Intel®/Altera® Quartus Lite 18.x Download

Requirements Traceability Matrix  (RTM)
Project Management
Mezzanine Board

The majority of Internet scheme and protocol information are from a few open public information sources on the net, IETF (Internet Engineering Task Force) RFC's that explain details on the application of the protocols used for both IPv4 and IPv6 as well as experimental protocols for the next generation Internet and the Network Sorcery web site.  The remaining of this series on the IoT platform will be from BASIL Networks MDM (Modular Design Methodology) applied with the Socratic teaching method.   Thank You - expand your horizon- Sal Tuzzo

Network Sorcery: http://www.networksorcery.com
The Internet Engineering task Force: IETF - RFC references
Wikipedia https://en.wikipedia.org/wiki/Main_Page

Memory Segmentation
The Memory Management Unit (MMU)
Virtual Address Space
Virtual Addresses and Page Tables
Extended Memory

Part 1  Introduction - Setting the Atmosphere for the Series (September 26, 2016)
Part 2  IPv4, IPv6 - The Ins and Outs of IP Internet Addressing (November 11, 2016)
Part 3  IPv4, IPv6 DHCP, SLAAC and Private Networks - The Automatic Assignment of IP Addressing (November 24, 2016)
Part 4  Network Protocols - Network, Transport & Application (January 10, 2017)
Part 5  Network Protocols - Network, Transport & Application Continued (Aug 17, 2017)
Part 6  Network Protocols - Network, Transport & Application Continued-The Ethernet Protocol(s) (Sept 21, 2017)
Part 7  Network Protocols - Network, Transport & Application Continued-The CRC-32 and Checksums (Nov 27, 2017)
Part 8  IoT Core Platform& Development - Embedded Processor Systems-(SoC)-(SIP) Core Processor -Embedded System Configurations  (Jan 12, 2018)
Part 9  IoT Core Platform Development - Embedded Processor Systems-(SoC)-(SIP) Core Processor -Embedded System Configurations (Mar 16, 2018)
Part 10 IoT Core Platform - SoC Core Processor of Embedded Systems-Product Development Management (May 5, 2018)
Part 11 IoT Core Platform - SoC Core Processor of Embedded Systems -Documentation Management Processes (June 27, 2018)
Part 12 IoT Core Platform - IoT Core Platform - Product Design  -Creating Conceptual Design Documentation (July 29, 2018)
Part 13 IoT Core Platform - Peripheral Interface Devices  -Peripheral Design From the Beginning (Oct 7, 2018)
Part 14 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design (Oct 29, 2018)
Part 15 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design-Continued (Dec 7, 2018)
Part 16 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design-Continued (Feb 11, 2019)
Part 18 IoT Core Platform - Peripheral I/O Development - Peripheral Device Real World Testing -Continued(Apr 25, 2019)

Publishing this series on a website or reprinting is authorized by displaying the following, including the hyperlink to BASIL Networks, PLLC either at the beginning or end of each part.
BASIL Networks, PLLC - Internet of Things (IoT) -Security, Privacy, Safety-The Information Playground Part-17 Peripheral I/O Design - Peripheral Devices- Real World Testing - (Mar 15, 2019)

For Website Link cut and paste this code:

• Main
• Archives
• Albums
• Links
• Admin

• Internet of Things (IoT) Security, Privacy, Safety -Platform Development Project Part-18
• Internet of Things (IoT) Security, Privacy, Safety -Platform Development Project Part-17

• BN'B Posts Q&A All Categories [4]
• General [0]
• Manufacturing [0]
• Product Design - Hardware - Theory & Practices [0]
• Product Design - IoT Hardware/Software [18]
• Product Design - Software - Theory & Practices [0]
• Security - Computer Forensic Science - Cracking/Hacking [0]
• Security - Network Cybersecurity, Policies & Human Behavior [0]
• Security - Product Development General [0]
• Security - Product Development Hardware/Software [0]
• Technology & Law - IP, Trade Secrets, Copyright, Patents [0]
• Technology Consulting, Contracts & NDA's [0]

• RSS 0.90
• RSS 1.0
• RSS 2.0
• XML