Blog BN′B

BASIL_NETWORKS


Designed & Made
in America (DMA)

ABOUTABOUTPRODUCTSSERVICESSUPPORTCONTACTARTICLESBLOG
BASIL Networks BN'B

The BASIL Networks Public Blog contains information on Product Designs, New Technologies. Manufacturing, Technology Law, Trade Secretes & IP, Cyber Security, LAN Security, Product Development Security

Internet of Things (IoT) Security, Privacy, Safety -Platform Development Project Part-14

saltuzzo | 29 October, 2018 15:25

Part 14: IoT Core Platform Development;- Peripheral I/O Device Design
The IoT Embedded Core Platform -Analog Input Peripheral Device Design - Continued

"As we get more technically driven, the importance of people becomes more than it's ever been before.  You have to utilize who you are in your work.  Nobody else can do that: nobody else can pull from your background, from your parents, your upbringing, your whole life experience." - David Carson (1955 - Age 63)

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)

Quick review to set the atmosphere for Part 14:
From the previous Internet of Things Part-1 through Part- 13:

  • (Worth Repeating) - Since the beginning of this series in September 2016 there have been many hacked IoT devices using COTS embedded hardware and software creating high visibility to security and privacy.  The current database of breaches encouraged us to present a more detailed hardware and software presentation to assist designers and educate new comers of the new challenges with security and privacy.  Due to the complexities of processors today we will continue to follow our technical presentation methodology, Overview - Basic - Detailed (OBD).  We will be addressing the many sections of the Core IoT Platform separately to keep the presentations at a reasonable length.  The full details will be presented during the actual hardware, firmware and software design stages.
  • The internals of the embedded processor IC's peripherals assignments.
  • Documentation categories, requirements, review & creation.
  • The Conceptual presentation of our Core IoT Platform Documentation
  • Brief Introduction to the Interactive Product Development System
  • Common Functions of Peripherals and data memory buffers
  • Introductions to the world of FPGA and CPLD development systems
  • Analog Input Peripheral Preliminary Design Requirements
  • Analog Input Functional Block Diagram
  • A/D Data Transfer Timing Diagrams
  • Control CPLD Schematic Diagram For the A/D Converter

What we want to cover in Part 14:

In this part of the series we want to cover more on the process steps that were performed to develop the CPLD and interconnections to the surrounding A/D converter and Programmable Gain Amplifier for the Analog input peripheral.

Lets Get Started:
The IPD Documentation - Developing Documentation Discipline
It is always beneficial to review the documentation process being used to keep the our development processes organized and to review the areas that have not been completed, not that we have to complete them in any order per ser,  it is to initialize a mind set for the section currently being developed.  The mind of the passionate creator is not a linear step function, 1, 2, 3 ...N process it fills in many pieces as the development progresses.

Organization and Project Management (PM) are important parts of any development project period.  However it is only a part of the project that keeps it on a direct path to completion.  The intent is to have a PM application that allows the entrepreneur can focus their passion for product design while intuitively keeping track of all the different aspects of product design.  As we will see as the development moves forward the organizational and security of the IPD system is a simple interactive step for each stage of the development which allows the creator to focus on the technical details of the design.

IPD System Directory Structure:
As we stated many times during this series that product development of any type requires a unique combination of documentation and mind-set for a successful product.    

Back in part 11  Figure 11.0 IPD Relational Databases  we presented the number of different databases that may be used for a full product development process, in part 12  Figure 12.5 IPD System Directory Structure we presented the preliminary directory structure for compartmentalization of the different document types during development..  Remember as stated before all of this development process was initially done manually for many years and has a proven track record for product development.

So now that we are into the actual development incorporating the IPD system lets present the updated directory structure that the IPD system incorporates to show how the system organizes the development.  Figure 14.0 shows the new directory structure of the IPD system we will be using for this development.   The directory structure follows the same philosophy as the Interactive BUS Protocol Development (IBPD) system of compartmentalization allowing document organization and security.   It is easy to create a directory structure that is organized, creating all the interaction with relational databases and interactive dialogs is what makes the IPD a useful tool in development.   This directory structure may also be maintained manually and is a good starting point with minimal effort to encourage product development discipline.

PICTURE_IPD_DirectoryStructure
Figure 14.0  Interactive Product Development (IPD) System Directory Structure

OK, why so many directories for product development?  There are several reasons, which we will highlight a few now and address more in depth as the series moves forward as we enter each of the stages.

  • Compartmentalization - of different documents and development stages, Business, Technical,  Financial etc.
  • Organization - Project level single top directory structure separates projects.
  • Security - Incorporates Compartmentalization security practices for controlled access of project directories and files.
  • Backup/Restore and Archive processes to insure all the required files and directories are included.

Many companies separate development into sections by design. there are financial, management, procurement, modular parts of a design, marketing and the list goes on.  The next issue is security which we just touched lightly on in part 12 and 13.  However, today security is an important function to maintain trade secrets and market share.  The IPD system controls access security for each project at the directory and files levels by user login and user pass phrase.  The IPD has several levels of integrated security and uses AES256 along with other propriety obfuscating algorithms; we will address this again later in the series when we get into the security aspects of the platform.

CPLD Interactive Dialog of the IPD System:
OK, lets look at the CPLD design and move forward.  The CPLD/FPGA Integrated Development Environment (IDE's)!  Due to the competition in the CPLD/FPGA industry these IDE's all have very competitive features like command line opening of a project which allow the direct interaction with the IPD system.  Figure 14.1 IPD System CPLD Dialog,  interactive CPLD dialog for the project allows easier program management and organization by a simple Click&Open function.

Many of the programmable logic IDE's if not all are project based, meaning they setup a separate directory for each device being developed.  However, what we have found is that many of them are not backwards compatible.  If you use a new version then the files are no longer compatible with the release that it was developed on.  This is also one of the several reasons we have several releases of the IDE's on our in-house servers.  For a single designer only backward compatibility is generally not an issue however, when there are several designers involved with a project this becomes a software compatibility issue and some type of control on application development software is required.  The IPD system CPLD interactive dialog allows application development software control of the different CPLD's for a project.  

At BASIL Networks we have several releases of our schematic capture and layout software due to non-compatibility upgrading issues and the time required to re-layout an older product that will not extend its life cycle, changes are not on the roadmap for them.  All companies from the single entrepreneur to the largest of corporations have these same issues to deal with.  For a larger corporation this can easily become a nightmare resource and financial burden on the company.  We were forced to make the decision that all new designs will be with the latest IDE's and we will face the same upgrading issues in a few years when updates are not compatible again.  For programmable logic IDE's there may be a slight header alteration for the HDL or RTL to make the source code transferable, which is a very small issue as compared to other IDE's.

IMAGE_IPD_CPLD_DIALOG
Figure 14.1  Interactive Product Development (IPD) System CPLD Development Dialog

The Quartus IDE from Intel/Altera which we are using in this project opens on a command line using a single file linking the device project and uses the file extension *.qpf.   From the file highlighted in the list it is ADC_CHAN.qpf.  The Application Program field at the top section of the dialog shows the application program icon and location as  "C:\altera\91sp2\quartus\bin\quartus.exe"  that will open the ADC_CHAN.qpf  CPLD design.  Every line item in the list has its own database record  and the CPLD design database used with the dialog as with the remaining design dialogs allow 256 unique designs giving the user the ability to have designs using different IDE's from different manufactures organized in a clean directory structure for the project with a Click&Open feature insuring repeatability and saving time.

From the directory layout we see that the CPLD directory is N:\IPD_IoT-PLATFORM\SS_CAD\IPD_CPLD.  The N:\ drive is BASIL Networks In-House off-line cloud server that is being used for this project.  The directory  IPD_IoT-PLATFORM  is the actual top level project directory we initialized in part 13 for the IoT platform project.  The SS_CAD\CPLD (SS_CAD means Save Sets for CAD type functions) and CPLD is the design subdirectory directory where all CPLD designs are stored.  From there we created the subdirectory ADC_CHAN to put the CPLD design in for the Analog Input.  The sub-directory ADC_CHAN is in a separate field from the directory tree in order to easily see the current design selected.  This can be created several ways either from the IDE or manually.  Project and design information are also important for program management and the interactive dialog shows information about the CPLD chip, the designer, creation date and time on project.  The project security allows full project encryption as well as directory and file encryption along with access control for the project controlled by the top level Project Manager.  The designer also fills in the abstract of the design to view what the design entails and is used mostly for browsing.  The machine ID and Login ID will change depending on the machine being used to view or modify the design and will be saved in the database last accessed fields for the top level manager to view.   The users may also use private AES256 pass phrases for each file which would be required to open the file.  If you loose the key or pass phrase, there is no Manager key to open any of the files.

[Selection_Menu]            [Top_Menu]

CPLD Register Assignments:
The next part of the ADC_CHAN CPLD design is the Register Assignments.  This is required to test the CPLD logic and timing for the 50MHz SPI interface in Figure 13.4B  and Figure 13.4C  along with the full CPLD register set Figure 13.5A and Figure 13.B.  

We have used Microsoft® Xcel, LibreOffice® Calc, OpenOffice® Calc spreadsheet type application programs over the years for the register and pin assignment functions. Table 14.0 A/D CPLD Command Control & Data Register Assignments below identifies the assignments for programming the A/D Analog Input CPLD.

A little note about the internal 8192 bit FLASH on the CPLD chip; this is programmable at this time so we will be able to test different security features we plan on as an add-in later in the series.  Once this is completed we will use a separate file to load the flash during In-Circuit-Programming of the CPLD.  This creates a fixed security feature that will only be capable of reading through a special entry sequence created by the designer and integrated into the software for the specific IoT Platform allowing each platform to be unique.  This will separate the physical hardware and insure that it is the right hardware being accessed.  There are several spare functions in this CPLD design since it was a re-use from other more complex designs.  We will return to these spare functions as we proceed to design other peripherals and maybe even combine them into a single CPLD or FPGA.

PICTURE_CPLD_REG_ASGNMENTS
Table 14.0  A/D CPLD  Command, Control & Data Register Assignments

[Selection_Menu]            [Top_Menu]

CPLD Pin Assignments:
OK, why do we want to assign pins first to the CPLD?  For the seasoned professional this will be a bit boring, however for our readers new to designing with CPLD's this excerpt added to the introduction to CPLD will give a bit more detail to the design experience.  The pin assignments along with the logic functions of the application determines how the pins are connected internally.  If the design is complex then timing issues will occur and the device may not perform as expected.  Figure 14.2 CPLD Typical Interconnection Matrix Array shows how a typical CPLD or Gate Array single layer is configured, some CPLD's and FPGA's have several of these layers vertically and interconnections vertically as well as same layer interconnects and they all have their propagation delay characteristics.

The Logic Elements consists of a complex array of logic functions that are programmable, each manufacturer has their own way of defining these logic block and are easily looked up on the Internet.  The I/O Blocks are the blocks for each pin allowing pull up/pull down Open Drain, Tri-State etc. pin functions while the logic elements perform the desired logic functions and eventually connected to I/O Pins.

Picture_CPLD_Mesh_Matrix
Figure 14.2  CPLD  Typical Interconnection Matrix Array

Each of these LE's consist of identical blocks of logic functions like AND,OR, MUX, REGISTER functions that are connected to several layers of a cross hatch matrices where each cross on the matrix is a connection point.   There are propagation delays when going from one interconnection to another as well as inter-layer connections where these delays can easily add up to several nanoseconds which can cause missing register loads and data transfers.  For our IoT Platform A/D Analog Input design we have a 50 MHz SPI controller, a 20ns clock width per bit and the data has to be stable for 10ns and then clocked into the register.  Considering the typical clock rise/fall times are under 2ns  that only gives us a 6 ns window to capture the data.  So when we look at the timing in those terms we see why we may have to select the faster CPLD.  The Intel/Altera MAXII series have a few different speed configurations, the average is 350MHz clock rates for the global clock input pins.  The global pins are special pins on the matrix that propagate directly through the matrix so the minimum number of interconnects are required to use the signals.  Our design does use one of those pins for the 200MHz clock signal that is used throughout the IoT Platform as a reference clock.   For further education on these devices, there are several free on-line video class room tutorials from beginners to seasoned engineers that you may take at your own pace.  Purchasing a inexpensive development kit for these is probably a good idea.  BASIL Networks, PLLC does not sell end user products, nor do we sponsor any manufacturers.  Distributors like Digikey® and Mouser® and others have evaluation kits for a good majority of chip manufacturers.

Ok lets tackle the CPLD Pin Assignment now which is required prior to "creating the schematic capture symbol" for the controller section of the Analog Input peripheral.  From Figure 13.3 Analog Input Peripheral Block Diagram  the part number of the Cellular-RAM or Pseudo SRAM memory chip is  [PDF]IS66WVE2M16EBLL-70BLI  for the 2Meg x16 bit  when the design was initially created a few years ago.  Today ISSI ( Integrated Silicon Solutions, inc.)  manufactures the 4Meg x16 bit (64Mbit ) in the same BGA(48) package and is in production, the part number is [PDF]IS66WVE4M16TBLL-70BLI.  We will look at both of these parts for the CPLD pin assignment.

The pin assignment objective is to have the shortest distance traces between the pins of each component attached to the CPLD.   This is done to minimize the traces on the PCB Layout and keep the trace impedance characteristics the same or as close as possible for each trace.  We will cover PCB Layout trace characteristics when we get to the layout part of the peripheral.

During this series we will be introducing the basics for the beginners and a quick refresher for the seasoned engineer.  I will be available to answer questions via the contact sheet on this site.  I will post the questions and answers with a link to a separate category for this series in order not to get the questions and answers buried in the blogs comments since we do get a fair amount or comments.

The Block diagram Figure 13.3 the grouping of the pins by function has been defined already so we will start there.  The largest number of pins are assigned to the memory chip.  The memory is a  48-ball TFBGA (Thin Profile Fine-Pitch Ball Grid Array)  the dimensions of 6mm x 8mm and a pitch of 0.75mm.  There are a few rules for BGA packages that should be followed for good engineering practices.  There are many tutorials and papers on PCB layout of BGA packages which we will cover when we get into the layout section of the peripheral, for now we will just look at the traces as simple lines.  There is logic in why this exercise is practiced prior to the actual layout, simply put, it is easier to do a preliminary pin assignment than try to assign 70 pins to the CPLD during layout.  Another reason is to minimize the number of PCB layers.  PCB Layers are in multiple of two, which doubles the process requirements during fabrication, hence increasing the cost of the PCB by almost double depending on the actual PCB yields and company producing the PCB.  Another reason as stated prior is the trace width and spacing between traces which effect the cost and yield directly.   The memory chip 48-ball TFBGA has a pitch of 0.75 mm (29.52 mils) and a ball width of  0.30 mm (11.81 mils) which running a 0.2 mm (8 mil) trace with 8 Mil spacing will produce a high yield PCB.  Also a  0.38mm (15mil) through hole with a 0.635mm (25 mil) pad allows both sides of the board to be utilized easily.  The TFQP 100 Pin CPLD has a pitch of 0.5mm and is 16mm square and the fact the all the pins are on the four edges of the chip makes it easier to layout.

Figure 14.3A shows the free hand traces for the pin assigning of the CPLD, Figure 14.3B shows the grouping of trace routes for the memory TFBGA out to one side of the chip to connect to the CPLD pins. The yellow pins are the address pins and the light blue pins are the data pins, The Red pins are the +3.3Vdc power pins and the gray are ground pins.  Since this is a re-use design we have already optimized the layout, however the exercise is well worth practicing for future designs.  PCB layout is an artist type process of spatial dimensioning, some of the best PCB layout engineers are center brain individuals that have artistic talents to be able to visualize unique logic patterns which both right and left hemispheres of the brain are uniquely connected.

Picture_FreeHand_Traces
Figure 14.3A  A/D CPLD  & Memory Preliminary Block Freehand Trace Route

You do not have to hand trace this entirely, just a preliminary to see if there are enough pins on each side of the CPLD to connect.  As stated some of the traces will be reassigned to appropriate pin numbers during the layout process.  Every designer has their own way of creating a PCB layout, however the most common areas are those that may be susceptible to crosstalk and other transients, those traces are usually shielded from other traces. the rest remains the decision of the designer and the area constraints of the PCB.  For the beginner, do not get discouraged, even some of the seasoned designers take a few tries before they get a working layout. For the seasoned, well, for myself, I generally get a good nights sleep and a fresh pot of morning coffee.  Some of the IDE layout packages have what they call "Auto-Routing" I personally avoid auto routing since it pure logic and will place via's and longer traces depending on the trace list sequence.  Human interaction and manual layout works best for me however, as stated every designer has their own way of designing just like artists their signature characteristics sow in their work.

PICTURE_CPLD_PinsGrouping
Figure 14.3B  A/D CPLD  & Memory Preliminary Block Trace Route Layout

In the process of the PCB layout for this re-use we tried several layouts to get the optimum for this design.  Although this design may be layered out on a simple two sided PCB it was designed on a four layer PCB with other analog designs for a specific application.  The four layer PCB choice was to include a ground plane and a separate power plane, giving the analog traces some shielding.

The actual Pin assignments for the CPLD is shown in Figure 14.4A CPLD Pin Assignments By Number  and Figure 14.4B CPLD Pin Assignments By Name.  BASIL Networks design methodology is to show both Number and Name assignments in spreadsheet form for easier PCB and Schematic capture symbol generation as we will see when we get into the next sections of the process.

The Pin Assignment by name insures that we have all the proper power and programming pins assigned properly.  What we have done here is to create a set of spreadsheets with the critical pin assignments for each of the CPLD manufactures series and started from there.  The Quartus Pin Assignment function in the IDE for the CPLD shown in Figure 14.3 will generally block the user from connecting to reserved pins on the component.  Pin assignments for the entire Intel/Altera CPLD MaxII line

PICTURE_CPLD_PINS_BY_NUMBER
Figure 14.4A  A/D CPLD  Pin Assignments by Number

PICTURE_CPLD_BY_NAME
Figure 14.4B  A/D CPLD  Pin Assignments by Name

We have found it is much easier to create a schematic symbol when the pins are listed by name and it follows the signal flow of the block diagram in Figure 13.3.   We finished assigning the pins for the remaining connections of which we did make changes during the layout process however they were only a few number changes that are expected during a CPLD and component layout process.  Schematic symbols and PCB footprints were created for the remaining components as well.  This design incorporated the 2Meg x16 PSRAM and the CPLD only had one spare pin.

[Selection_Menu]            [Top_Menu]

CAD Symbols
Now that we have the CPLD initial pin assignments grouped we are able to create a schematic capture library symbol for the components. There are only four IC's to this design, the CPLD, the Memory chip IS66WVE2M16EBLL, the A/D Converter AD7890 and the Programmable Gain Amplifier PGA281.  Figure 14.5A shows the pin assignment layout of the CPLD and since this is a custom layout care should be taken for the placement of the signals to make it easier to read the schematic capture drawings.  Figure 14.5B are the remaining CAD Symbols for this design, the A/D Converter 7890,  PGA-281 and the Memory IC respectively.  The CPLD Pin assignments are preliminary and you should expect to change these in real time during the PCB trace layout process.  During our layout process we did change several pins to reduce the number of via's in the layout.  Many critical timing designs also require controlled impedance traces in order to align the signal transmissions which would require reassignment of pins.  Yes, PCB's have inherent trace delays and are directly proportional to frequency (1/Time), so that gives us two propagation delays, one inside the CPLD and one on the PCB traces.   When creating a schematic capture symbol a starting point would be to layout the CPLD pin assignments that follow the block diagram, although there are many approaches to arrive at the best results.  This design selected to use the MAX-II -T100 series 100 pin TQFP CPLD which is a  3.3 volt device for the internal power and up to 5v for the I/O pins.   There are several places you can download free footprints and schematic capture templates for many of the components, the two that are most prevalent are Octopart and SnapEDA.  It is always a good practice to create your own within the CAD IDE you are using.

The actual interconnect to the IoT Core Platform has been left out at this time on purpose since we have not designed the remaining peripherals and the interconnect to the peripherals will be analyzed at that time.  To date we selected a CPU parallel interface architecture to connect the peripherals so it becomes a mechanical interconnect issue for now.

When creating schematic capture component symbols we find that as the number of pins increase so the page size of the schematic increases.  Some of our designs incorporated a 208 pin CPLD and that required a C size drawing by default.  For many years BASIL Networks standardized on a B (11"x17") size format, however as time moves on we changed that to a C" size (17"x22").  If you shrink these drawings to fit the printer page and they are reduced to the level that the pin assignments are not readable and the saving paper size purpose has been defeated.  Pick a CAD package that you are comfortable with to follow the series, they are all competitive and the end result will be the same.  It is the individual designer that determines the end result not the CAD package.

PICTURE_CPLD_SYMBOL
Figure 14.5A  A/D CPLD  Schematic Capture Symbol

Picture_ADC_Component_Symbols
Figure 14.5B     A/D AD7890 MSOP-10 Package , PGA-281 TSSOP16
PSRAM Memory Ball-48 TFBGA
 Schematic Capture Symbol

[Selection_Menu]            [Top_Menu]

A/D Analog Input Schematic:
To encourage documentation discipline we will add the ADC-CHAN Schematic Capture to the IPD system.  This allows a Click&Open design function, organizes the directories and saves time in looking for the design.  Figure 14.6 shows the PCB Schematic capture dialog for the ADC-CHAN peripheral.  The separation of development tasks allows the designer to track time spent for each part of the design and for the project manager to organize and present the design resources used for the project.

Picture_IPD_SCHEMATIC_DIALOG
Figure 14.6  Interactive Product Development (IPD) System PCB Schematic Dialog

For this series we are using Cadence OrCAD for the schematic capture to create the PCB Schematic design.  Most of the small companies have a single users license for each PC and probable only one or two.  Many CAD packages offer two forms of license, single user for loading on a single desktop and they are generally perpetual type licenses.  The other license type is a network license with a specific number of run time licenses allowed from an in-house network server.  Here are the issues that we have observed with network licenses along with the associated license control managers; they are a pain in a place where the sun does not shine.  Server maintenance generally changes thing with licenses and interferes with  server ID's where license managers have to be reloaded and validated.  Some use disk serial numbers, some use encrypted keys created from the servers internal setup and the technique goes on.   We encourage single user licenses mainly if the server fails or has to be changed you do not loose all the licenses and development is delayed for only one system.  For us here at BASIL Networks, since we collaborate with other seasoned designers across the country that all have their own private labs as we do, it is best to purchase a single user license to run on a desktop.  Creating a gold disk or full recovery image backup is a lot easier to recover and pick up where you left off, however if you have to replace the motherboard you will probably have to validate the license again.

For the actual design files we keep them on the in-house private cloud server that is not connected to the Internet.  For this series we allotted a drive on the in-house server and labeled it B:\  for those that want to follow along.   Servers running RAID is fine since replacing a bad disk may be done without turning off the server in many cases.

OK, the next step is creating the schematic, so here it is for the AC CHAN peripheral without the IT Core Platform interconnect just  the off page connections since we will be adding to this as we perform the designs for the remaining peripheral controllers.  We have not decided if this design would fit in a single larger package and allow us to add the remaining peripherals for the Core Platform.  We will decide that as we continue on with the series.  There are many times during a design that all the components seem to just fit into place and a single controller has the most advantages.  Figure 14.7 shows the first pass of the schematic for the AC CHAN peripheral.

PICTURE_IPD_SCHEMATIC_DIAGRAM
Figure 14.7  AC CHAN Schematic Capture Design

[Selection_Menu]            [Top_Menu]

A/D Software Setup Flow Diagram
All this fun stuff designing now leads us to see if it still functions the way we expect.  In order to do that we have to test the core functions of the COLD and in order to do that we have to simulate the programming and use the timing analysis tool that is part of the Quarts DE.  We will put together a small flow diagram to test the AC CHAN COLD timing and functionality before proceeding.  The setup timing test will only increment the memory address once and end the data collections in order to test the timing of the data transfer in the COLD.  All the status signals are shown in the timing diagram Figure 13.6 A/D COLD Conversion To Memory Timing Diagram.  To perform the test we simulate a program controlled Start Scan function.

PICTURE_ADC_CHAN_FLOWTEST
Figure 14.8  AC CHAN COLD Setup Timing Test Flow Diagram

 

[Selection_Menu]            [Top_Menu]

SUMMARY:
There are many approaches to interconnect the a block of peripherals to a BUS architecture, we are at the beginning of the peripheral and it would be advantageous to wait until we have a few of the peripherals designed to see how they would interact with different BUS architectures before making that decision..

Thank you everyone for the encouragement and kind posts on this blog series.  Our intent is to help educate the beginner and present a good review for design professionals of high quality design practices for developing product lines in today's multi-disciplined technical environment.  With the advancement of technology many of the simple functions like data collection has become common knowledge.  If we look at the various peripherals as different types of data input sensors just as the human body has sensors like touch,(pressure / temperature), smell , visual, audio and taste for those that would put something they are unsure of on their tongue.   These human sensors are all fed into the central cortex and distributed to various parts of the brain, bio-chemical (not silicon) central processing platform to configure some sort of reality as to how the sensors react.  The IoT Core Platform is no more than a controlled group of sensors or a data input platform to allow the data to be transferred and processed by a higher level of computational power.  At the end of this the IoT Core Platform becomes as a single multi-functional component that may be applied to many unique control functions. However to get to that level we still have to adhere to the engineering task of developing the various parts of the platform which has many parts or projects to connect together.  

The A/D Peripheral being  just one small part of our platform, which emphasizes the necessity of an organized product development protocol.  As we begin to answer the question "why an IPD system?"  We see that incorporating a IPD system we can reduce the design time as well as have a unique way to organize the development multiple projects and combine them into one project at any time.   All functions neatly organized in the appropriate folder with a easy Click'N'Open to continue the development process.  

As the series progresses the author will be available for discussion for those that want to follow this series in detail and conduct their own experiments.  Contact me directly through the BASIL Networks Contact Form.  I will create a sub category for this series on unique questions and answers as not to hidden by multiple post comments.


Part 15 Preliminary Outline" A/D Channel Hardware/Software Design: -Continued

  • Creating Device Driver Flow Charts for the A/D peripheral operation.
  • Adding other features to the A/D Channel

Reference Links for Part 14:

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)


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-14 Peripheral I/O Design - Analog Input Peripheral Design - (Oct 29, 2018)

For Website Link: cut and past this code:

<p><a href="https://www.basilnetworks.com/Blog/index.php?op=ViewArticle&articleId=19&blogId=1" target="_blank"> BASIL Networks, PLLC - Internet of Things (IoT) -Security, Privacy, Safety-The Information Playground Part-14 Peripheral I/O Development:-<i>Analog Input Perpheral Device Design (Oct 29, 2018)</i></a></p>


Sal (JT) Tuzzo - Founder CEO/CTO BASIL Networks, PLLC.
Sal may be contacted directly through this sites Contact Form or
through LinkedIn

Internet of Things (IoT) Security, Privacy, Safety -Platform Development Project Part-13

saltuzzo | 06 October, 2018 11:14

Part 13: IoT Core Platform Development: Peripheral I/O Device Design
-Device Design From the Beginning

"Two Roads diverged on a wood and I -I took the one less traveled by, and that made all the difference." -Robert Frost (1874-1963)

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 - Product Design -Creating Conceptual Design Documentation (July 29, 2018)
Part 14 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design (Oct 29, 2018)

Quick review to set the atmosphere for Part 13:
From the previous Internet of Things Part-1 through Part- 12:

  • (Worth Repeating) - Since the beginning of this series in September 2016 there have been many hacked IoT devices using COTS embedded hardware and software creating high visibility to security and privacy.& & The current database of breaches encouraged us to present a more detailed hardware and software presentation to assist designers and educate new comers of the new challenges with security and privacy.  Due to the complexities of processors today we will continue to follow our technical presentation methodology, Overview - Basic - Detailed (OBD).  We will be addressing the many sections of the Core IoT Platform separately to keep the presentations at a reasonable length.  The full details will be presented during the actual hardware, firmware and software design stages.
  • The atmosphere has been set for the Internet operation overview in parts 1 through 11.
  • The basic selection of protocols for the IoT Platform have been defined.
  • The conceptual functional block diagram of the IoT Platform has been presented.
  • The internals of the embedded processor IC's peripherals assignments.
  • Documentation categories, requirements, review & creation.
  • The Conceptual presentation of our Core IoT Platform Documentation
  • Brief Introduction to the Interactive Product Development System

What we want to cover in Part 13:
OK, since this is the beginning part of the development project after an introductory presentation of the Internet technology of which we will be in communication with, this is a good time to develop our engineering discipline and the documentation process.  The Interactive Product Development System presented here was developed in pieces, manually over many years and since we will be offering it at the end of the series I have incorporated several changes to put it in a full package.   For the road less traveled, we will use the IPD System in real time while we develop our IoT Core Platform since we will be addressing many different aspects of the IoT Platform Project to show a tool of this type is really a good practice to be encouraged.

We will dive right in to designing the peripherals for the IoT Core Platform.  The hardware and software/firmware will take a couple of parts for each peripheral while we include the IPD system with the process to convey the organizational concept of product design.  For those wanting to experience the time element involved in component selection and design feel free to list several of each type of component and verify the selection we have made.  I have a private link to contact me directly from the website and will answer any questions privately for those wanting to participate in our development process.

Lets Get Started:
First  - The IPD Documentation -Developing Documentation Discipline
As we stated many times during this series that product development of any type requires a unique mind-set and the combination of documentation of thoughts and mind-set are essential for a successful product.    As we stated there are many categories of documentation during a development project and the IPD addresses these as an open interactive system.  The user can create segments of each layer of required documentation as the innovation process develops then return to the selected document sections at a later date to pick up where left off to continue the development.  OK, a system like this does exist in large companies and takes a while to learn the ins' and outs', however as entrepreneurs and small companies we need something less cumbersome and intuitive as well as organizational to use as well as much less expensive.

The main purpose of the IPD is to have a project related documentation system for any type of development project.  Keeping the proper documents and design files in a project oriented directory structure and being able to have an abstract outline each file allows the designer as well as new designers that will eventually take over the project maintenance and changes for future releases   There are many different application programs that are used during a development project and handling all the different file type becomes difficult without some type of organizational application program, hence: the Interactive Product Development System.   There are 58 different directories that separate each aspect of the development process, allowing the user to incorporate writing, drawing and CAD, CAM application software for each part of the development while maintaining separate directories for each section of the development.

Figure 13.0 show the startup page and how we create a new Project hence: The IoT Core Platform" using the IPD system.  We already have the conceptual drawing completed so that would be the first to be added to the system. Creating a new project is easy as well.  We will spend more time on the IPD later, our objective is to interact with the IPD while focusing on the actual development of the IoT Core Platform.  The key features for this program is the top level manager controls the access rights to each section of the program.  All sections are entered from a login process that controls the available sections of the development process.  Encryption with a global standard AES256 key may be used or a separate key for each individual access may be set by the top level manager of the project.  Each project is handled separately or may be combined via the AES256 access key.  This allows multiple designers to work on different pars of the project they have access rights to.  The IPD will run locally on a desktop, an in-house controlled server or the cloud, however is it not recommended for the cloud since security is still an issue and trade secrets and proprietary designs should be kept in-house on a controlled server or an assigned workstation.

The IPD System will be available at the end of the series with added features from readers comments from this series.  There are several Reserved buttons for expansion of the program for those that wish to contribute, send me your request either in a file or message using the Contact Form.  To date this program runs on Windows XP, Win7.x, Win8.x, and Win10.x either directly on the local machine drive or on a server.

IMAGE_IPD_TOP_MENU
Figure 13.0 IPD Interactive Product Development System Top Menu Update

The main dialog allows the user to setup a default project that the IPD will automatically load at startup.  Each project has a 4096 byte abstract to summarize the projects description and any special notes that would be useful to those accessing the project.

Figure 13.1 shows the dialog where we can create a new project, open/edit/modify an existing  project.  The projects description is the same that is displayed on the startup dialog and uses a in system RTF editor to add comments to the project abstract.   The user may also browse projects anywhere the system allows access to see the projects that are stored.  One of the comments from a reader was to have a central database of all the projects that the IPD has handled as well as archived, we will be adding this to the program while we write this blog.

IMAGE_IPD_NEW_EDIT_PROJECT
Figure 13.1 IPD System Create/Edit/Open A Project

From this point one the project has been created the rest is simply used the IPD for its organizational and security features.   Since we already created the conceptual presentation we just simply add the file along with the API required to open / edit or modify it. From the dialog we also have a time stamp for when we started the file.  There is a add more time to the time elapsed working on this section of the project.   Each section has this feature in order to allow separate develop on each section.   The Project manager has the option of organizing all the different development times for budgetary purposes etc..

The system can handle up to 256 different documents along with the application program to open each document.  Many projects are broken down to sub-projects that are considered modules or sub-modules.  Each of these can be a separate project in a Sub-Project directory in order to keep them in the same top-level directory.  Each of the sub-projects have a unique set of databases that may be shared or kept separate.  We will get into that as the development project moves forward.  Full security access is controlled by the Project manager at all project levels.  Multiple IPD systems may be opened at one time on a single desktop to handle different projects separately on if multiple users are sharing the same desktop.  Each file that is added to the Documents dialogs has its own abstract section allowing the user to give a brief summary of the files contents or any special modifications incorporated.  Last access and creation dates are displayed for reference to the activity of the file selected.  ;All databases may be packed and modified for ease of maintaining the database.  Projects may be archived easily and restored to any directory the system has access to.  Each of the document sections allow the encryption of a single file for communications outride the controlled area if required. If the user encrypts the file with a user private key and looses the key there is no spare key or hidden Administration key to decrypt the file.  The encryption programs is separate from the windows AES encryption and does not use any windows encryption resources. Any mixture of files may be added to the documentation along with the application program to open them. We added the Visio drawing and part 12 of the IoT Platform Development Project series. We use an older html WYSIWYG editor, however there are many free open source and commercial html editors on the market that will run on a variety of OS platforms.

IMAGE_IPD_PRESENTATIONDIALOG
Figure 13.2 IPD System Adding A& Presentation Document

Creators / Innovators  mind-sets are all wired differently and face unique challenges in business when putting a product or product line together for development.  The entrepreneur mind-set, the small company mind-set and the large company mind-set, all have their pros and cons.  Regardless be it entrepreneur or company, at the end of development the documentation should be the same prior to entering a manufacturing environment.  The processes are very similar, the conception of the product or product line, the creation of the high level business presentations that sum up the costs and market risk to obtain the business go-ahead, the technical presentations detailing specifications, testing and validation to solidify the budget "expectations" to create Proof of Design (PoD) and Proof of Manufacturing (PoM).  Then the manufacturing requirements presentations for supply chain, manufacturing costs, testing, packaging and build size.  The differences between the entrepreneur, the small company and the large company are the Return on Investment (ROI) statistics, development resources and of course time to market. Prior to the PoD or PoM the only deciding factor is the accuracy of the documentation created to present the project.

For a large company to enter a market arena, marketing has to show the expected ROI that meets the company guide lines for product development.  For a small company the analysis is similar however the ROI numbers are smaller since the overhead is much smaller.  For the entrepreneur it is generally the question; are the overhead bills being paid?  What will the initial prototype cost and will the market bring in a profit for a few years.  The documentation process should still end up the same, however less costly for the entrepreneur and small company which is where the IPD systems is effective.  As mentioned before I am updating the IPD software as this series as we develop the IoT Platform and there are many new features that I have learned writing this series and am very thankful for the encouragement from all the readers.

[Selection_Menu]            [Top_Menu]

Common Functions of Peripherals:
From our mind-map view in Part 12 on IoT Platform Peripheral's Interface Function Map  (will open in a new window) shows that we will be required to address several different types of peripherals from a single interface structure.   Our intention here is to develop a common hardware function that will allow full control of the devices and data transfers.  This allows us to incorporate different peripheral IC's into the design with simple translation (off the wall marketing plug for the IBPD System on our website) for the different IC's I/O BUS protocols.  Remember we previously discussed the pros and cons of all the peripheral devices embedded with the processor combined on a single chip leads us to separate peripherals and make this a Drop-In accessory.   This approach was how the actual desktops started where you had a processor and support I/O peripherals around it.  

In order to design an efficient multi-peripheral control interface we have to understand and document the various types of BUS translation requirements for each peripheral type.  This is where an FPGA or maybe a CPLD would be the best way to translate the different bus protocols to a single BUS protocol for our IoT Platform.  A single I/O Peripheral protocol will allow software efficiency and hardware stability.  Granted it is a bit more design work but it is a road less traveled in the industry due to pure market drive to compete not necessarily for quality/performance.  In the long run this final multi-peripheral design is a drop-in block for any or the fast changing processor designs to complete an IoT Platform for the next generation.

Peripheral Type

Number Channels

Data I/O Throughput

BUS Interface

Datasheet

Creator / Inventor

 

 

 

 

 

 

I2C® Controller

3

1MHz Max

8 Bit Parallel  50MHz

PCA9663

I2C UM10204 2014-04-04

1-Wire® MicroLAN

1

14Kbps

1-Wire®

TBD FPGA

Maxim Integrated

SPI Controller

1

3MHz

SPI

TBD FPGA

Motorola-Freescale

eSPI Controller

1

33Mhz

eSPI

TBD FPGA

Intel Corp eSPI

CAN Controller

1

1Mbps

SPI 10MHz

 MCP25625

Microchip

LIN Controller

16 1 Master

LIN 19.2Kbit/s

LIN Devices

 

BMW-Audi-Volvo-Mercedes

RS232 Serial

1

1Mbps

Seria/Parallel

TBD

EIA RS232

16/32 Bit Digital Parallel

Standard

Max Chip Speed

Parallel

TBD FPGA

 

A/D  - Analog Input

1

1MHz SPS COTS

Serial SPI

ADAQ7980

Analog Devices

D/A - Analog Output

1

1MHz SPS COTS

Serial SPI

AD5542A

Analog Devices

Thermocouple Temp Input

 

1MHz SPS COTS

Serial SPI

LTC2508-32

Analog Devices

         

 

PWM Output

multiple

upto 10MHz

Serial Digital Stream

TBD FPGA

 

SQI Controller

4 chan eSPI

50Mbps plus

Serial/Parallel 8/16/32 bit

TBD FPGA

 

           

Ethernet Controller

1

1 to 10Gbps

Parallel / Serial/ PCIe

 

 

Storage RAM Devices (SQI)

32Mbit

80MHz Read

SQI

 SST26VF032

Microchip

DMA Controllers

4

upto 50MHz

Parallel 16/32 bit

TBD FPGA

 

Interrupt Controller

8

upto 50MHz

Serial/Parallel 8/16/32

TBD FPGA

 

Table 13.0 IoT Interfaces Functions List

Each of these peripheral devices in the Table 13.0 Interface Function List are readily available in IC's and chip form with some type of BUS interface protocol designed in, some serial some parallel.  We will now look ate each of the BUS protocols and design a translator to form a standard BUS protocol our Core Platform.  This will make the Peripheral block a Drop-In device that is capable of being interfaced to any processor or desktop which is the objective of the common BUS architecture.  "A road less traveled" due to market stress and competition pressure to get a product to market before the competition, however a better long term solution when the road is paved.

The Peripheral Interface Function Map shows a common BUS structure that interfaces all peripherals. We will look at this closer when we analyze the timing features a typical parallel and serial bus structure.    To start we will make the decision to insure that all peripherals will have a set of control and data registers.   Over the years of developing peripherals for computer systems there have been may shortcuts to peripheral designs.  Some eliminated Write/Read registers for Write Only Registers and Read Only Registers expected the software to maintain what it wrote to the registers.  part of this was due to the space availability in the logic used for the design.  Today the density has increased to a high enough level that R/W registers are not an issue and in many cases are preferred.  Our design will use R/W register sets for each peripheral.  One of the reasons is it does not require extra CPU instructions to determine that state of the chip as we will experience.

The BASIL Networks Website has several of these interfaces with technical information readily available, so as not to retype everything lets get to the design organization of this platform.  From the list we see that there are several types of interface protocols that we have to address.  The main question at this point is what are the expectations of the data rates for each of these peripherals.  Lets try to answer logically for several applications to show the range of data transfer rates that will determine the amount of buffer memory required to fit the majority of applications for the IoT platform.

The Interface Protocol - Serial, Parallel or Both:
As we observed in Table 13.0 the selection of the IC's for this project primarily support the SPI BUS as the digital data transfer BUS protocol.  Several of the selected peripheral IC also have other data transfer BUS protocols however using a parallel bus several discrete peripheral IC would be very cumbersome to layout on a small PCB as well as maintain a reasonable noise margin for performance of all the peripherals.  Another argument is when we select the CPLD or FPGA pin assignments will be a concern.  It would be easier to have the parallel BUS architecture connect to the MAIN CPU and the peripherals that have to be external such as the high Speed A/D and D/A and others be connected serially or other transform BUS methodologies to adapt to a single BUS Protocol architecture.

Peripheral Characterization for Real-Time Data Acquisition:
The first question that comes to mind is, would we have an application that would use all the peripherals sending and receiving data at the maximum speed of the peripheral?  The answer is possibly if it is operating as a remote controller where environmental parameters are part of the control sequence.  So lets look at what real world data collection would entail and put some real parameters to the data transfer processes.

Side-Note: As a bit of mind-set guidance to encourage creativity; if you ever have the opportunity to develop a friendship with an artist, painter, sculpture etc. ask to spend some time with them while they are creating.  The experience is totally priceless, for you will be able to see both right and left brain working together uniquely to create, the order will also be unique since every mind creates its own order.  The Author is truly fortunate since my wife is and exceptional artist and well balanced in her creativity that I have the pleasure of being with. Ok, that's the personal side, and Oh by the way - creativity is very personal and unique so just allow your mind to flow and visually imagine the pieces being put together on the brains right side and the brains left logic side will guide you to complete the creation in its natural order.  That being stated,  we will not take these peripherals in any order, since that is generally how the creative mind works, which ever comes first since the subconscious already has this worked out, we just have to bring it to the service of the conscious right and left parts of the brain, hence the visual and logical.

Peripheral Memory Buffers:
The is a lot to be said about putting an internal real-time memory buffer on a peripheral device.  Many peripherals incorporate them such as the Ethernet IC's,  Analog Input peripherals, Analog Output peripherals for Analog Waveform Generations (AWG), digital I/O devices for fast sequencing and the list goes on.  Keep in mind not all peripherals incorporate memory buffers, in fact there are more that do not incorporate memory buffers.  The ones that do not have memory buffers expect the users program to perform that function which does have its limitations for periodic data transfers on a multi-tasking  system.  For our IoT Platform lets shoot for the best performance and incorporate a memory buffer, it is easier to take it pout than redesign it back in. As we analyze each peripheral and weigh data transfer requirements and price/performance will determine how we handle the additional memory buffers which is not a difficult decision to make when all the facts are presented.

[Selection_Menu]            [Top_Menu]

An Introduction To CPLD/FPGA Considerations:
CPLD's, FPGA's and other programmable logic devices and arrays are now mature in the industry and discrete logic is only used as a fill in when you run out of gates in the programmable device and need one more to finish the interface; or require higher voltages or currents for a signal line.  For our IoT Core Platform it becomes obvious that we will be using CPLD's and FPGA's as we develop the platform.  There are a few parameters to keep in mind when designing with these devices that we will present below.

We selected Intel®/Altera® Quartus for the IDE, no real preference just had to pick one and we have more experience with Intel® through our client preferences than Xilinx® or Lattice® although all will work just as well.  You can go to the Intel®Altera® website and download any version from the archive to accommodate various FPGA and CPLD devices or the latest release Quartus Prime® and Operating Systems you are using to follow this design process from XP to Win 10 x64 or Linux.  We have several versions on our development systems running Windows 10 Enterprise due to the fact that each of the free  versions either adds or removes certain devices one different versions.  The free version handles many of the applications, however if you require some complexity the  license release has many more features.  Here at BASIL Networks, we avoid and development that incorporates the cloud for security reasons at this time.  Some of the older releases allow full development without an Internet connection which we have incorporated on several clients manufacturing internal private networks.  For this CPLD development we are using release Quartus Web version 9.1 SP2 that runs on  Windows XP,  Windows 10 and Linux.  The majority of our designs are single FPGA or just a couple of CPLDs per PCB and it is easier to use the free release since it fits our needs.

There are many different flavors of CPLDs and FPGAs and each manufacturer has their own way of maintaining non-compatibility with competitors.  For those engineers and beginners that want to change the selected types that is fine.  The other issue is supply chain as we mentioned in prior sections of this blog that the Mergers & Acquisitions over the past few years is creating havoc for designers and manufacturers that are not receiving information on what items will be discontinued and when.

We already researched several devices for the A/D input peripheral and ended up with a selection for the IoT Core Platform for CPLD's.  They are the MAX-V (1.8V) and MAX-II (3.3V) devices,  We selected the 3.3 Volt devices for this design and selected the 100, 144 and 240 pin QFP (Quad Flat Pack) packaging as resources as needed. So far it appears that a few CPLDs will meet the requirements of the peripherals for the IoT Core Platform peripherals.

CPLD and FPGA are characterized by the Logic Elements (LE)  or Logic Units (LU) and Logic Array Blocks (LAB) for CPLD's and of course for a Field Programmable Gate Array it is characterized by the number of, wait for it, Gates.  The key differences between CPLDs and FPGAs  as follows:

  • CPLDs are PROM based and do not require any external memory to load at power on
  • CPLDs incorporate a complex programmable Logic Element or Unit and have fixed logic limitations
  • CPLDs Logic Array Block consists of several Logic Elements that are connected to a grid matrix connected to the pins.
  • CPLDs have a security feature that disables reading the configuration and must be completely erased before reprogramming.
  • FPGAs are organized in a gate array matrix and are configured discretely as gates the way may CPU's are configured.
  • FPGAs are Static RAM based and require external memory to store that gate array matrix connections and must be serially loaded at power-up.
  • FPGAs are more flexible and many pin configuration features
  • FPGA timing and propagation delays are smaller that CPLDs
  • FPGAs are a bit more complex to secure the device due to the external configuration EEPROM

Programming these logic devices and gate arrays have come a log way over the years, they can be programmed in circuit easily.  It took a few years to design a suitable language to program these devices and what emerged was Verilog Hardware Description Language (VHDL) or HDL.  Companies that sold these CPLDs and FPGAs offered several compilers to easily program them, some free some paid license.  Not long after when companies like Altera, Xilinx and others realized that they sold more chips when the software was distributed free and that is where we are at today.  OK, lets get down to some important design parameters when using these devices.  If this is your first encounter with these devices and HDL or RTL (Register Transfer Level)  programming, the Internet has many short introduction and advanced programming courses for CPLDs and FPGAs.  We are not going to cover that here since every IDE has their unique way of handling the programming.  However, Veriliog and  HDL are behavioral hardware descriptive languages all have their limitations. Verilog is case sensitive who's syntax is similar to the C programming language and is a better choice for ASIC (Application Specifif Integrated Circuit) designs, VHDL is case insensitive and opposite to that of Verilog, VHDL contains more constructs and is a better high level modeling environment for FPGAs.  There are many companies that will create a fixed IC (ASIC) from an FPGAs VHDL design.  ASICs have their advantages over FPGAs, a CPLD is a mini ASIC that is programmable and does not require an external memory device to load it at power-on.

Pin Count:
The Pin count for these devices vary from 20 to several hundred on FlatPacks and BGAs (Ball Grid Arrays) along with various pin spacing (pitch).   The number of pins are easier to calculate when a functional block diagram is developed of the peripheral or device it is being used with.  Generally the CAD software used to design the CPLD/FPGA will supply information during compilation if the design will fit in the device selected.  Pin count primarily is a deciding point during the design process.  As the pin count increases the cost of the device increase and they not necessarily linear or proportional.

Programmable I/O Pins also vary depending on the number of LE and LABs or Gates the device has.  The MAX-II series handbook  Section 1-3 (page19) gives the characteristics for the MAX-II series we are looking at and the I/O Pin count. We are looking at 76 pins for the 100 Pin device and 116 I/O Pins for the 144 Pin device.  The max propagation delay for the 100 pin device is typically 5.4na and will clock at 304 MHz.  OK, what about FPGA's ?  Well for security at this time we will look at CPLD's for a few reasons, first- the MAX-series CPLDs have an 8 Kbit FLASH that can be used for security access and ID, second the complexity of the design parameters are not that complex and can be kept in a small package of a couple of chips.

Device  Package & Pitch:
The spacing between pins on a FlatPack pads or the ball size spacing for a BGA are very important during the board layout and determine the manufacturing PCB fabrication process which reflects the yield and price/performance of the PCB.  We selected the Quad Flat Pack for the core platform because the trace/space ratio for the PCB gives a high yield factor than that of Fine Pitch BGA devices.  Flat Packs are easier to assemble and are easier to inspect to name just a few of the advantages.

Device packages can become an issue when the design and layout software does not have a validated footprint for the part selected which requires the designer either designs a footprint or purchases a footprint from a company that creates them.  Creating a footprint depending on the CAD package can be an issue and is easy to have placement errors pop up during fabrication and assembly.   For our Core Platform CAD software we are using OrCAD and have been since the early 90's, however Mentor graphics and others are fine for this development and if they are what you use just reenter the schematic.  For our lab here we have a large validated ORCAD library of footprints that we have used in several designs, many of which we created ourselves and paid the price of validation during PCB fabrication and assembly. One of the prices we are still paying for is upgrades to the CAD packages for our many footprints that are not compatible to the latest releases.  Developing a design reuse library grows fast over the years and can easily become time consuming and costly to convert over.  Unfortunately there is no easy way to fix this dilemma since all of these packages have to deal with these issues.  The closet one that we have experience with so far was Altera, even though it was acquired by Intel designs that have been developed on 10 year old MaxII software are easily upgraded to just about any of the product line.  This is not a plug to use the product, it is just some experience gained.  When you look at the competition like Xilinx and others they all use HDL and RTL for the design environment therefore it is only reasonable that the core designs will be easily transferred.  Printed Circuit Board layout software is unique to the designers of the package and do not have to be compatible in any way, libraries and footprints creation is unique to the software which makes it YBIYSWI  (You Buy It, Your Stuck With It)  type software.

Device Propagation Delays:
Welcome to the world of speed (Signal Speed Only).   We will address this during the actual CPLD design process. The CPLD design application software will allow a timing analysis of each section.   Signal path from LE - LAB to other LE and LABs effect the propagation delays as the signal passes through the elements.  OK, now down to the peripheral design itself.

[Selection_Menu]            [Top_Menu]

Analog Input A/D:
There are many questions initially when designing an A/D input peripheral, especially for a IoT Platform for many different applications.   There are many ways to accomplish this however, over the years we have come up with a group of features for A/D input designs that do address many data transfer features.  Creating a set of analog input specifications does require a bit of experience designing these, however for the beginner the Internet is full of a Analog Input peripheral cards that will give you a good reference of what would be flexible.  One of the most useful features of an analog input is incorporating a programmable gain amplifier.  This allows the flexibility to adjust the input range to accommodate many different analog sensors.   Another feature would be a programmable sample rate for stable periodic sampling.  We selected to incorporate a large memory buffer as well.  Table 13.1 below is the set of specifications that BASIL Networks standardized over the years below.

  • A/D 16 Bit Differential / Single ended input
  • Programmable Gain  x 1,  to 1024 programmable in 11 steps
  • ±10.240 Volts to ±9.7656 Millivolts full scale.
  • 2 Meg x16 SRAM data input buffer each channel for 1MSPS A/D
  • 1 Meg x16 (10ns) for 10 to 100 MHz A/D  8 or 16 bit
  • Expandable to 16 Meg x16 (Cost/Performance)
  • Programmable Number of  samples,Memory Buffer Control
  • 1 Meg to 100M SPS (Samples / Second)  Pending on A/D
  • Internal / External Clock and Synchronization Control
  • 32 bit Programmable Clock Controlled Sample Rate Timer/Counter
  • Digital Input/Output Trigger Control Start/Stop Sampling Data
  • 1 MA, ±10 Vdc Calibrated Constant Voltage & Current Sources for Bridge Measurements
  • Programmable DC Offset Control ±10 Volts DC Voltage

Table 13.1 IoT Platform A/D Input Specification list

To keep the blog for each part to a reasonable length, we already performed the research for the component selection for the analog input peripheral and created the block diagram from the set of specifications.  There are many A/D converters and programmable gain amplifiers (PGA) to choose from with new components being presented monthly.  A good exercise for both beginner and experienced designer to research the various types and features to develop a discipline as well as a table for supply chain availability and component selection for future design requirements.  The table can be incorporated in a component selection project using the IPD system for other designers in your company to use.   One of the issues we discussed earlier on Mergers and  Acquisitions pertaining to discontinued components encourages designers to research components and manufacturers at a business level as well to see the stability of the company.

For the A/D input peripheral we selected a CPLD device, which may easily be transferred to a FPGA to combine other peripherals if this becomes a contract issue once we go through the PoD (Proof of Design) stage.  This also allows us to establish a BUS protocol to interface for all peripherals.

From experience we selected a byte wide databus and a separate register address bus to access the internal control registers of the COLD.  This allows a wide range of control processors with a reasonable number of wires to control, also to jump ahead a bit the reason for the 8 bit bus is we ran out of pins on the COLD.  Table 13.2 is the component list for the A/D Input peripheral for the IT Platform.  The reasoning behind this choice will become evident as we move forward with the design process.

A/D  - 1 MHz A/D Converter

  • Main reasons is the PI BUS interface to reduce the number of PCB traces
  • Single Trigger input to start the Conversion, no special register setup required
  • A/D technology is a traditional SR (Successive Approximation Register) AC.
  • 1us conversion time (1 Meg Samples/ Second
 

PGA281 - Programmable Gain Amplifier

  • Large Gain Span (1/8 to 128 V/V)
  • Very Low Noise
  • CMRR 140db
  • High Input Impedance
  • Low Offset Voltage 5uv
  • Good Slew Rate
  • Good GainBandwidth Product
  • Good EMI Rejection
  • Allows many sensors including thermocouples and RTD temperature elements
 

IS66WVE2M16EBLL - 2Megx16 PSRAM Memory

  • Pseudo Static Ram Technology
  • Simple Async SRAM BUS interface Parallel
  • 70ns Write Time
  • 25ns Read Time
  • Small 48-ball TFBGA
  • Largest available at time
  • Possible 4Megx16 Future Release FFF (Form,Fit,Function) Drop-in
 

CPLD Altera - MAX II 100TQFP

  • Altera MaxII 100TQFP CPLD 5ns chip
  • 512 x16 internal FLASH for Device ID and Security
  • Small package, easily programmable in-circuit
  • Free IDE software Quartus II
  • Cost Effective
  • Assign custom part number to the device

Table 13.2 IoT Platform A/D Input Component list

Figure 13.3 shows a functional block diagram of the A/D input peripheral for the IoT Platform.  I know we just jumped right into the functional block diagram of the A/D peripheral without discussion of each part of the peripheral.  OK, There are only a few  function blocks to the A/D Peripheral and using a CPLD makes this easier to design the A/D Input peripheral they are:

[Selection_Menu]            [Top_Menu]

The A/D Converter IC
SO, the question should have surfaced as why did we choose a serial A/D and why just a 1 Megasample converter?  To answer the first Why a serial output put A/D, well it only needs three wires to run.  Trigger, Serial Data out and Clock.  The second, why only 1 MSPS, well, the device exists and has very good conversion specifications.  1 MSPS A/D is a good sample rate to handle many audio analysis directly and with RF up/Down converters can handle many of the 1 MHz bands of RF applications.  Another reason we selected a 1us A/D is the memory buffer selected is price/performance and mechanical packaging.

The SPI to Parallel Interface
 This is simply required to translate the A/D data to transfer it to the CPU and Memory.

The Memory Control Interface
There are several advantages of designing in embedded A/D memory buffers.  First, data collection is CPU independent and guaranteed to be periodically stable.  Second, Data collection is a retained for retrieving at a later time. Third, data can be collected at higher speeds that the peripheral system throughput is capable of.

Adding a Memory buffer to an A/D peripheral allows collecting data at a controlled stable periodic rate.  It also adds a capture feature that may be triggered at the maximum rate of the A/D.  We selected 2 Meg x16 (32Mbit) RAM. This is a Pseudo Static RAM (PSRAM) it is a dynamic RAM with and internal hidden refresh and has a 70ns asynchronous write cycle allowing a stable fixed interface for 1 megasample data collection.  Also there is a possibility that this chip will be available in a 4Mx16 IC.  Also the expansion of adding several of these chips for special applications will accommodate the 23 bit memory address interface giving up to 16 Meg x16 data buffering.

The Counter/Timer Control
 This is a 32 bit counter timer that is used to control the data collection in 20ns intervals to beyond 85 second intervals based on a stable over controlled base clock of 200MHz.  The counter is programmable by the user.

The User Interface Control
 The User interface allows the user to interface with a variety of applications from synchronizing with a remote start of data collection to using a external clock.

The BUS Interface Control
The BUS interface selected is an 8 bit  4 address line CPU type interface. This is mainly because of the pin count of the 100 pin CPLD that we are using.  We could go with a larger CPLD however the cost from 100 to 144 pin to accommodate the speed exceeds the price/performance ration that would be comfortable.  This is derived from the functional block diagram of Figure 13.3 as we will see shortly.

From all the discussion and specifications we are now able to construct a functional block diagram as shown in Figure 13.3 below.  The CPLD has to be designed to accommodate all the control and communication setup for the A/D peripheral.  From the block diagram we should be able to develop the timing diagrams for the critical portions of the A/D peripheral as well.  Experience is the best teacher and as you practice creating these block diagrams and timing diagrams they will become easier as you let your mind become accustom to developing this type of logic. "Repetition is the mother of retention" - Samuel Rodenhizer.  

IMAGE_AnalogInputBlock
Figure 13.3  Analog Input Peripheral Block Diagram

The next stage of the peripheral design is to establish a timing diagram to be sure that we cover all the timing requirements of the components connected together.  It is a good engineering practice to develop a timing diagram of how you want the circuit to function and compare it to the CPLD timing analysis once we put it in the CPLD.  There are unique timing Propagation delays when using CPLD's that we will see when we start designing the functions in the CPLD.

OK,  the next important step after we get the block diagram complete is to calculate the number of pins the design will require.  Remember in the past parts we discussed pin assignments with embedded processors and all the peripherals on one chip.  This will determine our interface BUS architecture approach for a price/performance for the optimal design.  From Figure 13.3 Analog Input Block Diagram we derive the following functional pin requirements for the real world outside the CPLD.

  • Memory Address  =  23 pins
  • Memory Data  = 16 pins
  • Memory Control Read/Write pin. = 2 pins
  • A/D Control SPI  = 3 pins
  • PGA Control  =  4 pins
  • User Front End Interface = 10 pins
  • - Sub-Total  = 58 pins

So, before we address the CPU interface BUS structure (a bit of a pun) we already have used up 58 I/O Pins.  CPLDs programmable pin count for a 100 pin CPLD is limited to 76 I/O Pins.  That leaves only 19 pins free for the BUS interface.  So I guess the 32 bit parallel BUS architecture is out for the 100 pin device package.  The next CPLD size up is 144 pins that has about 116 I/O Pins, allowing 58 pins for the 32 bit interface, a bit overkill for a 32 bit bus.  However if we use an 8 bit bus we would require a total of 8 Data, 4 address, 4 control = 16 total which leaves us 3 spare pins.  This is also the best price/performance and mechanical size choice for the peripheral.  The A/D input peripheral consists of  4 IC's and a few support components without the constant voltage and current sources.  We will get to the constant voltage and current source later in the process.

The next issue is the number of Logical Units or Logic Elements required for the CPLD and will the design fit in the selection.  This is realized when we start the design and run timing analysis to see if it meets the speed requirements.   A discussion on an effective way to present HDL (Hardware Definition Language) and RTL(Register Transfer Level)  and Block Schematic Level used in programming Logic devices is always a challenge of education.  The all around standard is HDL older acronym is Verilog HDL (VHDL) and RTL both are C like structured high level languages to represent logic elements where as the Block Schematic Level language is a much higher level representation of a function.  It is similar top a function in C and the programming of the actual function line by line.  For the beginner it is best to use the Block Schematic Level and all of the Block Schematic have an HDL code assigned to them that has already debugged and functional as long as you follow the rules of the Blocks Function, just like programming in C or PHP languages.  So for the remain of this part of the series we will present the CPLD design then go through and show reasoning on why for simpler designs a block schematic is easier and for complex designs as we will see as the series moves forward other approaches will be discussed.

CPLDs have the resources to handle many interface requirements including Schmitt Trigger, PullUp, PullDown Resisters, Open Drain and Tri-State programmable pins.  If you give a set of specifications to a dozen designer and just say to use some type of programmable logic you would have a dozen different designs all doing the same thing, some using CPLDs, some using FPGAs.  The way the author approached this design is designing each of the modules separately then interfacing them for the final design.  This is much easier when working with CPLDs and FPGAs as we will see.

The CPLD will require a 50MHz SPI to parallel translator to handle the clock from the A/D and the serial data stream along with the associated registers to buffer the data and setup registers.  Since all the timing requirements are given on the A/D and SRAM datasheets we can construct a timing diagram for starting the A/D and putting the data into memory.  We will compare the datasheets to the final timing for the peripheral.  

 

OK - Where do we start the design, what section of the logic is timing most critical - simple the A/D 50MHz SPI interface translator on steroids.  From the ADAQ7980 datasheet the full conversion timing is shown below in Figure 13.4A for a single conversion.  From our experience to capture data serially we generally use a clock that is at least four times the frequency of the data we want to capture, so for this it would be 200 MHz for capturing a 50MHz serial datastream.  If you remember back the slower serial protocols like RS232 used a clock 16 times the serial data stream, well 800 MHz would be a bit too high of a frequency for standard COTS CPLDs.   Using a stable TCXO (Temperature Compensated Crystal Oscillator) will work just fine as a reference frequency as we will see when we move forward with the design.

IMAGE_AD_TIMING_SINGLE_CVRT
Figure 13.4A  A/D Single Conversion Timing Diagram

OK, now that we have the functional timing diagram lets just dive in and use the CPLD development program to design the 50MHz SPI interface translator.  Figure 13.4B shows this in a Block Schematic Level diagram that is part of the Quartus IDE.  

PICTURE_AD_SPI_CPLD_BLOCK
Figure 13.4B  50MHz SPI Interface for the A/D Converter

The timing analysis for the 50Mhz SPI to 16 bit translator interface is shown in Figure 13.4B.  The CPLD  used to perofrm the design was the 100Pin MAX-II C5 device.  We ran the timing at 80 MHz and it ran fine. That gives us a good design margin for this peripheral.  It took a total of 46 LE (Logic Elements) for this section of the design.   Since we control when the SDO data stream will start for the timing simulator we too the liberty to only make the conversion time shorter for clarity only. in reality the full conversion time would be 1 micosecond.   Our main interest in timing is the serial translator to 16 bits.  I ran the A/D Translator at higher speeds to see if we were at the CPLD speed limits and it ran at 80MHz to give a design tolerance for prop delays is shown in Figure 13 4A, 13.4B and 13.4C show the SPI interface translator of the peripheral.  

PICTURE_ADCHAN_SPI_Timing
Figure 13.4C  50MHz SPI Interface Timing Analysis Diagram

Figure 13.4D below shows the function block of Figure 13.4B for the A/D Translator.  OK by this time we see the convenience of building the CPLD in sections and testing each section as we design it, then saving that section as a Block Schematic Level Function.  The educational part of this processes is the fact that you can create a complex design and reduce it to a single block of Input and Output signal names, then use it as a single component to be added to other complex blocks.   This is what makes the CPLD and FPGA such a useful tool for designing logic devices.  The other main feature that makes this technology useful is the actual pin assignments are flexible.  Putting this device down on a PCB and connecting pins to a CPU BUS architecture makes this useful since you can add components to the CPLD or FPGA to within the full resources of the device without having to re-layout the PCB.  Also during the PCB layout we can assign pins to keep the PCB traces in a group to minimize runs.

IMAGE_CPLD_AD_SPI_SYMBOL_BLOCK
Figure 13.4D  50MHz SPI Translator CPLD Symbol Block

So as we see for those starting out with any of the CPLD, FPGA IDE platforms, the Block Schematic Level is capable of handling many of the design tasks.  You always have the option and capability of adding HDL blocks for the IDE as well.  When designing with CPLDs a block schematic is all that is needed for this design since it is primarily register control for the data transfer.  Although we selected a CPLD for the PoD (Proof of Design), keep in mind that HDL is a standard language and may be transferred to other IDE platforms to FPGAs if so desired on the final release if you add other functions to the A/D peripheral.

Since we are incorporating a memory buffer on the A/D channel there are a few features that would add flexibility and data collection stability to the analog input.  These are a periodic trigger to automatically trigger the A/D on a programmable interval, a programmable number of conversions comparator to take a smaller burst (less than 2 meg) of data points, an external clock synchronization input.  The control lines are shown in the block diagram above in Figure 13.3.

[Selection_Menu]            [Top_Menu]

From this point we should look at the timing from the A/D SPI translator to the buffer memory.  Creating a timing diagram of this processes will aid in the developing of the peripheral since we already have the A/D single conversion timing diagram.  This design does not fall into the complex category so a simple timing diagram is all that should be necessary to start the design process.  The diagrams developed for this peripheral are shown in Figures 13.4B and 13.4E show the timing diagrams for the A/D SPI translator data transfer for a single conversion and A/D conversion data transfer to memory which are the critical areas for the data collection.  The remaining parts of the design are simply holding registers for the counter/timer and control registers for the users interface as follows

IMAGE_AD_2_MEMORY
Figure 13.4E A/D Conversion To Memory Timing Diagram

Now that the main timing diagrams for the data transfer from the A/D converter to the buffer memory have been created we can now start to design the CPLD control.   As stated I am using Intel®/Altera Quartus® 9.1 Sp2 since it has devices that we will be looking to use for our IoT Platform continues being developed which are not in the new 18.x lite release.  90% of designs that incorporate a single FPGA or CPLD may be easily designed with the Lite or free Web version.  If you want to include some of the IP modules then a license is preferred and required.

I have several of the free Quartus releases on my system since each release adds and removes some of  components.  The new systems relies on the cloud to do the timing analysis and for propriety designs that is not advised it would be advantageous to keep propriety information in house.  Release 9.1 Sp2 handles all the MAX II designs that we have been using for the past several years and do not have to be connected to the Internet to run, this gives us control of the designs.  The archived releases like 9.1 Sp2 are also available for download from the Intel website along with both paid and free releases, a link is available at the end of this part after the summary.  We did load Quartus Lite 18.0.0.614 on Windows 10 Enterprise 64 bit, transferred this design and it ran fine.  This just validates the stability of the M&A of Intel/Altera and to date keeping compatibility across the board.

OK, Figures 13.5A and 13.5B show the compete A/D Channel Peripheral CPLD Block Schematic and timing diagram respectively.   This design is part of several re-use designs from BASIL Networks Design Library which are being incorporating for this series.  There is more to be done before this design is a plugNplay device for our platform.  The next steps are setting up a register assignment matrix outlining the functionality for each register as well as addressing requirements for programming, analyse the timing, address the program flow of operation and more to be presented.  The Byte (8 bit) CPU BUS interface protocol make this compatible with any embedded CPU.


Figure 13.5A  A/D CPLD Block Schematic Design

OK, the design pace is a bit fast at this point, however do not worry about it, we will slow down in the next part to cover the design methodology etc. for this A/D peripheral.  This high level presentation is to give the reader a design to review and question to learn the VHDL IDE  platform development process.  There are many readers more familiar with other CPLD and FPGA VHDL development IDEs so we will keep this at a level that to allow the capability to transfer to other VHDL  IDEs.

PICTURE_IoT_images/AD_CPLD_TimingScaled.jpg
Figure 13.5B  A/D CPLD Conversion To Memory Timing Diagram

[Selection_Menu]            [Top_Menu]

SUMMARY:
As we see there are many different aspects to developing a product.  The A/D Peripheral is just one small part of our platform, which emphasizes the necessity of an organized product development protocol.  The question arises and probably will throughout this development process for those that ask the question "why an IPD system?"  The answer for this part is, the A/D Channel peripheral is just one part and this may be setup as a project or sub-project as well as a reuse project just as the CPLD has been for BASIL Networks Design Library.  It is much easier to setup a CPLD for reuse since it is just a single package IC as BASIL Networks has done to be called up a few years later when the need arises.  This is the main purpose of the IPD system allowing the organizational processes required for successful product development.   All functions neatly organized in the appropriate folder with a easy Click'N'Open to continue the development process.  Much of the IPD system is being rewritten since it has been developed over the years with small additions of code and this gives me the opportunity to update the software and allow for the development of other products as the series continues.

We are now in the world of peripherals and sensors to monitor and respond to the physical world.  Just as we have our human five physical sensors, touch, visual, audio, smell and taste, they all have their sensor operating ranges.  The human brain, the unique bio-chemical (not silicon) central processor receives information, organizes and interprets this information to give a perspective on reality for each individual.  The unique perspective of system integration.   The IoT (silicon) on the other hand is uniquely programmed by humans to perform specific functions that with the right type of sensors be capable of interfacing to what ever the real environment requirements may be.

I am always thankful for my readers, their public and private comments for the encouragement it gives me to continue this series and the great input for additions to the IPD system.


Part 13 Preliminary Outline" A/D Channel Hardware Design: -Continued

  • Creating the register assignment addressing format for the CPLD
  • Creating a Schematic for Layout
  • Addressing the programmability of the A/D Channel
  • Adding other features to the A/D Channel
  • Adding the design to the IPD System to maintain organization in the development
  • Keeping track of the new sensor technology innovations.

More to come in the series

  • Protocol Hardware - Ethernet
  • HS-USB
  • WiFi devices
  • Bluetooth Devices
  • SQI, SPI, I2C,
  • Analog Inputs, Analog Outputs
  • Digital Parallel Ports
  • PWM ports
  • Software tools for embedded processors
  • IDE- Integrated Development Environment
  • Macro Assemblers
  • Compilers
  • Hardware Design Tools
  • and more ....

Reference Links for Part 13:

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 14 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design (Oct 29, 2018)


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-13 Peripheral Interface Devices -Peripheral Design From the Beginning (Oct 7, 2018)

For Website Link: cut and past this code:

<p><a href="https://www.basilnetworks.com/Blog/index.php?op=ViewArticle&articleId=18&blogId=1" target="_blank"> BASIL Networks, PLLC - Internet of Things (IoT) -Security, Privacy, Safety-The Information Playground Part-13 A/D Peripheral Design:<i> (Oct 7, 2018)</i></a></p>

&

Sal (JT) Tuzzo - Founder CEO/CTO BASIL Networks, PLLC.
Sal may be contacted directly through this sites Contact Form or
through LinkedIn

1 2 3 4 5 6 7  Next»
 
Powered by LifeType - Design by BalearWeb
Copyright© 1990-2018 BASIL Networks, PLLC. All rights reserved
webmaster