BASIL_NETWORKS


Designed & Made
in America (DMA)

ABOUTABOUTPRODUCTSSERVICESSUPPORTCONTACTARTICLESBLOG
BASIL Networks Blog BN'B | IoT Core Platform Project

23 Mar, 2020

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

Part 21: IoT Core Platform Development;- Peripheral I/O Device Design
The IoT Embedded Core Platform -Peripheral Devices Real World Testing - Continued (Update May 14, 2020)

"The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency.  The second is that automation applied to an inefficient operation will magnify the inefficiency." ( Bill Gates - Oct 28 1955 - )

As we stated in past presentations in this series development costs are easily exceeded when the performance expectations and in that case performance requirements are not documented properly, hence: the infamous "TBD" -To Be Determined.  This forces a direction change "AND" direction changes are commonly not listed as part of  performance expectations.  Sometimes the development "process" is faulty or just plain broken period.  The intent of this series in not to maintain the insanity of over budget development costs but to disrupt it in order to allow the creation of new habits that will give a solid foundation for engineering practices to be successful when starting a development project.

For the new designer that is taking on the learning of CPLD and FPGA design, "Each design completed is experience for the next lever of development."  There are only experiences and techniques that will bring you to the advanced level of applications.

IoT_Index Quick Links

Quick review to set the atmosphere for Part 21:
Every new year technology advancements exceed the previous years, we get to apply some new technologies released to gain experience.  This past year 2019 many new devices and IC emerged on the market for developers and applications for the IoT arena.  We will address some of the new devices and in fact may have an impact on our IoT Core development series.  This is the new reality of product development in a fast changing technology environment, sometimes the product becomes obsolete before you are able to get it to market.  Project management becomes a bit challenging when faced with obsolescence during development   Simple buy for the end of life becomes a marketing nightmare knowing that the competition will release a competitive product with the latest hardware while your product is using obsolete or discontinued components.  Designers and development integration becomes a real design dilemma determining if the replacement "If There Is One" will cost a complete redesign or a firmware/Software update and more.

So as of this writing here is what has been happening in the micro silicon embedded world,   A couple of new embedded processors have emerged from all the Mergers & Acquisitions and many processors have been discontinued.  Performance and features such as higher core speeds and multiple cores make it applicable to many AI (Artificial Intelligent) applications.  Several interface ICs have been released that may help the interface sensors etc. along, however careful consideration has to be taken to insure that the interface will be around for at least five years to accommodate the embedded lifecycle requirements.

It is easy to loose focus on the project with all the new technology being released so a quick review to remain focused on the series.  This series is focused on the development of a Core Platform IoT applications and has a dual purpose, first an educational project development for the entrepreneurial mindset along with applications, second the implementation of remote sensing and control incorporating safety, security and privacy over a wide range of peripherals including wireless.  This should be kept in mind since we will be designing in some redundancy for reliability and security.  For the yourg newcommer to product design and development if you are chosed to be mentored by a senior accept humbly, it will be the most rewarding experience of earned knowledge you will every have.  

Since the wireless industry and advanced since the introduction of the IoT devices we have also started a new series on Wireless technology in a separate category, Wave Phenomenon, Antennas & Radiation in the category of Wave Propagation and Antennas.

The ITF development Project:
The ITF did create a change in direction, however did not change the desired results, this is not only common in development projects but is some cases required to meet the desired expectations.  The issues here are handling multiple projects, resources available and the changed timeline, just a short change in direction to complete the objective.  A validation that the real time product development process is far from being a linear process from conception to finished product.

Remember changing direction overnight does not mean changing goals our the final destination, it is just a better way to insure you will reach the desired destination.  In my years of exposure to the design arena as a designer, troubleshooter and mentor I have had the honor of experiencing innovative and passionate creators to realize that the creative thought process of an individual is not a linear step function, 1, 2, 3 ...N, probably because humans are not robots, that follow a preprogrammed set of processes as some may think of engineers.  The innovation of the human mind subconsciously is always performing scenarios to find the best solution for the task at hand and "developing habits along the way".

We will pick up from the last couple of parts in the series that cover CPLD#1 and CPLD#2 to put us in perspective for a complex design.  In Part-19 the digital I/O section of the ITF which included CPLD #2 was presented.  Due to the complexity and size of the blog only the first part of the Digital I/O was presented which included the following sections.

In Part-20 the continuation of the digital I/O design which included the internals of CPLD#2 registers, preliminary flow diagram and pin requirements of the CPLD and the first pass CPLD#2 design.  The important part of this section was the templates for tracking and creating PCB footprints by pin number and pin names.

What we want to cover in Part 21:
In Part-16 through 20 we addressed the issue of why we should consider testing of the peripherals (Proof of Design) PoD with a prototype build to insure when we interconnect several of the peripherals the throughput required for the applications will be met.  This allows the opportunity to change the development direction from the peripheral point of view if performance expectations become an issue. Developing a test methodology that will be used for testing peripherals for the platform keeping in mind peripheral throughput limitations. These are new habits being developed at a conscience mind set level that will connect to become the default critical thought process during development.  With that stated we will continue moving forward with detailing the Interface Test Fixture (ITF) CPLD #2.

Updating the IPD project documentation for the ITF (Interface Test Fixture) to keep track of the development process, "Documentation is a living process during development", a good habit to make!  The reference for the ITF is the functional block diagram Figure 16.1

Lets Get Started:

Some questions answered from our readers
"What happen to the series?,
"It has been a few months since part 20 publication, are you going to continue the series?
To answer the above two questions - YES the series will continue.   BASIL Networks, PLLC own and maintain several on-line servers as well as off-line servers all located on-site. We are in the process of upgrading them to the latest and greatest compliant requirements aw with all upgrade and new installations this took "longer" than planned, HHMMmm I think I said that about product development timing some where, well again we have added another first hand experience to our portfolio. Cool   We also started a new blog design category as we stated several times in this series about wireless and security, this new blog is addressing the wireless section and as always we start at the very basics and work up to the expert level for our readers.  The new blog is Wireless, Radiation and Antennas.  Yes, I know it was mentioned and linked a few paragraphs back. It is the old poetic license of repeating ones self three times, so that leaves one more time somewhere in this part.

Refresher on Security,  CPU Code and Encryption:
When designing products that are controlled by some type of processor keeping a security mindset should always be an active part of the design process.  There are several sections of a security policy to be taken into consideration when designing any product that will be connected to a network be it global or local.   Access security implementation is by far the most time driven authentication process today.  From Single Password Authentication to Multi-Factor-Authentication software driven it takes time to access and perform all the decryption, table look-ups and more.  Most financial and many government sites have incorporated MFA and generally it is less expensive to incorporate a software change than to upgrade physical hardware.  A few of the top level questions to address for the security poplicy are:  Who will be accessing the device?,   What type(s) of encryption to use?,  Who owns the keys?,  Are the encryption keys changeable?,  are just the few top level ones.  We will cover a few ways of insuring security and privacy for the IoT Core Platform as we move forward.

OK, why the security refresher?  This is where we incorporate the mindset to design in access security, proivacy and safety for the I/O part of the IoT Platform.  What does this have to do with the Core IoT Platform?  Putting security in the ITF allows us to test different access methodologies for access control.  For the ITF the design incorporates the CPLDs internal FLASH that will allow the user to embed a series of encryption keys as well as ITF device serial number, and other identifying characteristics which may also be encrypted and assigned to a specific PC it is used with for added security.

It is much easier to incorporate hardware access security in the initial design stage than attempting to add a hardware security feature after the design is complete with some type of after thought patch.  The MAX-II  EPM1270T144C3 incorporates an 8192 bit FLASH that may be organized by byte or word and configured during the CPLD programming stage as 1024x8 or 512x16.  By enabling the security bit the FLASH and the CPLD configuration are not readable to the user, however the ability to completely erase the device remains, keeping the data from being read.  This is a good start, however we still have to create a security policy to implement into the CPLD FLASH.  This is addressed later in the series.

ITF CPLD#1 A/D vs CPLD#2 Data I/O Peripheral:
A brief comparison of the CPLD#1 A/D design and CPLD #2 High Speed Digital I/O Design.  Both incorporate a SRAM buffer to collect data at a periodic programmable rate or manually triggered externally.  However the design parameters are completely different, for one the high speed digital I/O requires a 10ns static RAM and the A/D is much slower 1us conversion time so a 1 typical PSRAM of 55ns is sufficient and much less costly.

A/D Channel vs Data I/O Throughput 
A quick comparison of the two technologies, the A/D Channel is a 1 us Sample rate via a 50MHz 16 bit  (20ns x16) Serial interface.  The actual conversion time is approximately 700 ns which allows ample time for the serial data to be transferred into the PSRAM on board without missing any points until the number of samples has been obtained.

The Parallel 16 bit interface in CPLD #2 is different since we require the full 50 MHz or faster x16 bit transfer rate without missing points.  This simply states that the full time cycle to write to memory is less than 20ns in order to meet the 50 MHz transfer rate.  The main difference is that the memory type for this requires a full Static RAM type of 10ns or faster verses a Pseudo SRAM type of speeds 70ns typical.  The faster the SRAM the higher the cost also the faster the throughput and the more power required which generates more heat.  There are a smaller selection to choose from when designing with 10ns or faster SRAM devices.  There is a list in the Reference Links of the selected high speed SRAM devices for this project at this time.

Peripheral vs. Functions
When designing any product including test fixtures the Peripheral vs Function discussion will always arise to insure the best price per performance is addressed.  With the technology advancing at such a rapid rate ICs are being release on a regular basis to eliminate support ICs as well as reduce design and testing time.  There are pros and cons with all designs and they have to be addressed.  The approach we are applying in the development of the ITF is flexibility and programmability and separating the front end sensing to separate IC(s).

Create a Preliminary Timing Diagram
As we stated before creating a preliminary timing diagram of the expected performance takes some practice and is always recommended for speeds that get close to the limits of the CPLD and will aid in troubleshooting timing propagation delays after programming.  Figure 21.0 is the preliminary timing diagram for CPLD #2 and as we see it would require capturing the data in a 5 ns window in order to be ready for processing in 10ns.

The other issue is as we review the pin count it appears that will not be room to incorporate the designs for the serial ports, hence, the SPI, I2C and QSPI types of protocols.  We could always incorporate a third CPLD, however it may be better to actually use the 16 bit interface and create the serial interface CPLD as an actual IoT Platform serial Interface then use the IFT to test the data transfer for the IoT Peripheral device itself.  Remember the IoT Platform I/O will remain a constant while the processors evolve. The expectations is to design a 10ns data throughput interface with the maximum data width possible.

alt
Figure 21.0   CPLD #2  Preliminary Timing Diagram

From the IDE functional block diagram in Part-20 and the Preliminary timing diagram above we should be able to easily create the simulated IDE logic timing diagram with all the delays and the DMA performance for CPLD #2.  The IDE release 19.1 Quartus Prime Lite Edition for the CPLD is available for download in the Reference section below.  We will use an older release 9.1sp1 for this design for the time being since we have not had the time to fully evaluate the new release and test the differences that have been completed to date. To keep this consistent we will recompile later after the design is complete and compare the differences in releases.  Prior to Intel/Altera M&A Altera several of the releases of Quartus Web incorporated sets of different CPLDs and selected FPGA and they recommended that you use the release that is required for the device of choice, however a lot has changed since Intel is now merging this with their product line.  We have to look at redesigning several in-house devices since they were discontinued that has caused some issues in the lab as many R&D labs have encountered.  

During the timing setup a few design issues came up that have to be addressed.  The Functional block diagram is correct, however the implementation of the design has limitations and will not meet the expected throughput.  So what is missing for the CPLD #2 design that should have been presented at this time.  Lets take a look at what preliminary design procedure requirements for CPLD #2.

We have the following completed

OK, what we have left out is the preliminary functions I/O Register Map assignments.   Why do we want to do this prior to the design, well, since we did not create it on a spreadsheet the programmer will have to figure this out, not a good idea.  What could possibly go wrong if we just do it later? The black hole cliche of all times.  So lets complete the process requirements, it is easy to just not use a bit in a register than it is to try and add one later.

There are many schools of thought on register implementation for peripherals and there are same implementations that make it extremely challenging for software to get around and are not recommended.  Some general guidelines of register implementation to follow that insures a hardware/software balance.:

Following these guidelines allows the software configuration to be grouped in a contained block of memory to be easily programmed and viewed.  The register sets for CPLD #2 are all eight bit (byte) registers to meet the pin count of the 144 pin CPLD and leave a few pins for modifications.  A good rule of thumb to follow is always try and stay below 80% of the available capacity of the device using to allow manual changes to the routing to address unique propagation delays..

Peripheral Control/Status Register = 8 Bits - 1 byte wide register

From the above list CPLD #2 requires 14 byte wide registers for setting up the peripherals functions as well as the 14 control lines to load each of these registers. This is a good place to start.  The front end of CPLD #2 for the Register set would require 5 bits to address the uo to 32 registers and control strobe lines combined to initiate the device manually and set the different mode configurations.

CPLD Simple Propagation Delay Test
In Part-14 we touched lightly on the internals of the CPLD connection matrix and the internal Logic Element blocks. This is one of the areas that many talented engineers are stilled challenged with and it is not going away either. It is the internal connection matrix that contributes to those propagation delays that make or break a design.  Just because a design works with the fastest speed device and you are below or within the lower speed device parameters that costs less does not mean the lower speed device will work the same way.  Connections matrix is a large contributor to propagation delays however complexity and available Logic Element gates and where they are between Logic Element blocks adds to the interconnection issues.  Here in the lab we have experienced this many times where we pushed the CPLD to 90% of resources and changed speeds and still had to redesign the CPLD to make it work.  Now take this understanding and think you can easily change manufacturers or CPLD series and expect it to perform the same or better without real world testing.  One of the areas we have found to be root cause of failure is with major bit shift switching from 111100001111.  The matrix in a CPLD are not neat and organized as if you would hand wire it, they are routed via an algorithm similar to auto route in a PCB and that can get cluttered.

The typical misconception with programmable logic devices from engineers and engineering managers that have not had the opportunity to actually design with them is "Oh, just make changes to the CPLD/FPGA and we do not have to run a new PCB", well folks that is not a good thought process to be transmitting.  As we will see below the same design acts completely different with just a change of the device speed and nothing else.  Propagation delays are variable depending on the complexity of the design.  Internal noise (crosstalk) with adjacent interconnection planes can cause false triggering and other types of spikes throughout the device.

Ok, now that we have created a preliminary timing diagram for CPLD#2 of the critical data flow of the memory data I/O it is time to encourage good design behavior when designing with CPLDs and FPGAs.  A good general practice when designing with CPLDs or FPGAs is to test the waters on speed and general throughput when attempting to push the limits.  Sometimes boolean logic just seams illogical when it comes to connecting points in a CPLD and FPGA matrix.  To Test the CPLD being used, a simple circuit was compiled and simulated to show the timing diagram of the functions shown in Figure 21,1 incorporating a simple pipeline binary decoder 1 bit to 2 line and 2bit to 4 line decoders with an gated clock.

IMAGE_CPLD_TEST
Figure 21.1   CPLD #2  Speed Test Function

The expected digital sequence for this design is shown in Figure 21.2 and is a basic binary decoder 2 and 4 line with a front end latch for one clock delay.  The front end latch is to insure that the decoder input is presented with the binary bits all at the same time in order to eliminate spikes that will cause other timing issues.  The GateEN is the standard D-Type F/F and it operates on the rising edge of the clock and is expected to respond in less than 1ns.  Figure 21.2 shows what is expected and the simulation results Figure 21.3 and 21.4 are two different results.  This is one of the reasons it is encouraged to create an expected digital timing diagram when ever possible prior to actually using the IDE to design the CPLD or FPGA.  Over the years we have found that the simulation process with IDE's does perform well, however being able to simulate all functions for the design is where many fall short and the problems show up in real world application after the product is on the market.

CPLD_2_Expected_Timing
Figure 21.2   CPLD #2  Pre-Timing Diagram Expected 

To start the highest speed CPLD available was selected for the simulation for the test design in Figure 21.1.  Figure 21.3 shows the simulated timing for the 144 pin device selected.  To understand the propagation effects of speed to configuration of the CPLD we will run the same timing simulation but with the slower device.  The CPLD The actual part for this simulation test is the EPM1270T144C3 for the fastest speed and EPM1270T144C5 for the slowest speed both handle speeds faster than 10ns.

CPLD-Test-SimTimingScaled.jpg
Figure 21.3   CPLD #2  Speed Test Simulated Timing Fastest Device (C3) 1270LE Timing

Observing the two timing diagrams we easily see that the device becomes unstable at the same frequency.  When we look at the pin to pin delays for the different speed devices C3 vs C5 we get 6.3ns and 10.1ns respectively.

CPLD_Test-SimC5Scaled.jpg
Figure 21.4   CPLD #2  Speed Test Simulated Timing Slow Device (C5) 1270LE

Keeping the same design just changing from a 1270 Logic Element device to a 570 element device Form Fit Function the results for the C3 devices are also very different as shown in Figure 21.5 below.  The MAX-II EPM1270T144C3 and the EPM570T144C3 are form fit pin interchangeable however the performance differ greatly with just a simple design configuration.  Timing changes with complexity and pin assignments as well.  When we look at the pin to pin delays for the different architecture 1270LE C3 vs 570LE C3 speed devices we get 6.3ns and 5.5ns respectively.

CPLD-Test-SimC5-570Scaled.jpg
Figure 21.5   CPLD #2  Speed Test Simulated Timing Fast Device (C3) 570LE

The question is what is the stable operating frequency for the devices.  We ran a series of test frequencies from 10ns to 1ns clocks  and the high speed device was selected as well as adding some delay functions in the clock line.  When you get below 10 ns it is very typical that you will run into propagation delay issues when as the available LEs (Logic Elements) of the CPLD become part of the design.  The experience we have seen here in the lab is every unique interconnecting trace adds about 0.4ns delay so if you have to go through 3 unique interconnects before you get to the pin you already exceeded the clock time of 1.5 ns for a 3ns clock cycle as shown in the timing diagrams.  Looking at Figure 21.4 we see that the propagation delays for DOUT2 exceed the clock and the output is completely missing.   Also DOUTA and DOUTB overlap which would cause other timing issues if DOUTB must start after DOUTA ends.  OK, now think of the fact that manufacturers make design updates to these devices at random. This makes interchangeability a very risky business for critical reliability devices.

There are ways to compartmentalize the design and keep the I/O ports for the section close to the LE and not split them between several LEs.  After thought additions is where the problems arise the most since the addition may have to reconfigure the CPLD differentially to accommodate the functionality designed in and the device becomes unstable.  The in-depth analysis of CPLDs and FPGAs go beyond the scope of this blog series however, it is important to present some of the challenges attributed to CPLD design when designing peripherals since the majority of designs today incorporate some from of programmable logic.  As a refresher on why the 144 pin CPLD was selected, mainly because it has been around for many years, designed into many devices with no end of life in sight at this time.  The MAX II and the MAX V are 2 different pins, MAX-II has 116 I/O pins and MAX-V has 114 pins.  We have not tested the performance or Form Fit Function physically in the lab since all our designs use the MAX-II and the devices are still readily available for all levels of designs.   Although the selected device is more costly the choice for same performance the MAX-II EPM1270T144C3 is the one we will use for this design. If this were going into a large volume product a separate PCB attached to the ITF could be used to AQL (Acceptable Quality Limit) evaluation of devices per lot.

Register & Bit Assignments
The correct design sequence is to create the CPLD #2 register map first, then create the bit assignments for each register prior to the actual design of the CPDL.  Yes, we did this backwards not just to show the time it requires to undo the design then implement the new updates, but in this case we attempted to try and reuse some of the assignments from the reuse design library.  The reuse design was taken from another project that involved a memory buffer.  Well the implement of the reuse parts and adding some functions that are required for this design just added more delays which  from several years experience with timing delays it would be better to just redesign the CPLD from scratch..  This is typical of many reuse scenarios and will now cost more time to undo and redo the design, this is our learning curve on using a design that are close to what we wanted but not exact.  Also when we canalized the propagation delays the throughput transfer speed also fell short of the expectations.  

The Register and Bit Assignments will be presented in Part-22 of the series along with spreadsheet templates.

How to Obtain a Finished ITF:
Our plans when the ITF is finished, is to offer an ITF to the public that has many more features than the one being developed for this presentation.  We already have completed two different PoD products to get ready for manufacturing and offering custom development for contract manufacturing companies and the entrepreneur small company that want to setup a development test base for future and present development contracts.  Please use the BASIL Networks Contact Form to be put on a mailing list when we are ready to supply the manufacturing prints if you are interested in purchasing the entire system manufactured and tested.

[Selection_Menu]

SUMMARY:
OK, this is a lot to present in a single part as with most of the parts of this series as we dive deeper into the designing devices.  The reuse of similar designs has it pros and cons, in this case it was a con since the timing of the design caused the redesign of the interface.  In many cases modifying a design ends up taking longer and incorporates less functionally that would have been to have the flexibility and freedom to do the design from scratch.  Many discussions with senior engineers and innovators have confirmed this through the years.  The difficulty lies with those that make the decision for the engineer and have not been in the design field for some time.  There is no disrespect meant with that statement, it is just a fact of human nature that when you are away from the details for a while you only focus on the results and not the process to get there; and by the way, as it should be, however when the facts are put on the table those managers (leaders) trust those that are at the detailed level and follow that lead and tend to managing the project.  This behavior of trusting the front line knowledge has been a proven process for a successful project development.  So, why would you have high level knowledgeable individuals on a field of interest drawing a salary and not listen to them? Cool that works the majority of the time and is what a responsible team is not only required but is how a team is expected to perform. It has been said by many of lecturers through the industry from different fields "Engineers design and build cities, Managers run them after they are built".  Ok, end of lecture to encourage engineering and managerial behavior

Updating and Modifying CPLDs / FPGAs
Here in the lab we have been very fortunate until just recently that our internally designed and developed test fixtures have stood the test of time for almost 20 year.  We still have some XP systems still running mainly due to third party PCI cards that will not run in any of our Windows 10 x64 Enterprise systems with PCI slots.  Some of our internally developed test equipment that incorporate discontinued CPLDs have to be redesigned.  When we looked at the replacement cost of some COTS instrumentation the lab requirements were just not available in a single product as well as the price being out of the expected budget.  The best approach is still to design the test fixtures to meet our needs with components that are anticipated to be around several years.

As shown in the above in Figures 21.1.through 21.5 FFF (Form, Fit, Function) does work but not exactly the same propagation delays add a high risk for critical equipment. This FFF discontinuity is also effective by revision changes in the IC itself.  Several programmable logic IC manufacturers have pin-to-pin replacement for their series of CPLDs, however think of a revision change in one of the devices that are labeled FFF in the series and is changed out for more LE's  or to add to that a different manufacturer and a new PCB layout.  We all get the picture now; so what is the solution.?  Building a physical prototype and test, test and test again for all functionality.   

Over the years the major contributions to the timing and propagation issues were designs focused for the selected CPLD / FPGA series that approached the maximum resources available in the device. This contributed to major carry glitches usually four bit and above blocks  111100001111 along with the data path within the interconnecting matrix for the chip.  As we see the FFF factor sort of falls from the rooftop of a tall building when upgrading to the next pin interchangeable device in the series.  What we also be noticed is using actual I/O pins as test points in the simulation since they are also routed through the connections matrix, when removed from the final design the device also performs different.  Many engineers use internal pin assigned names that are simulated at the point inside the chip that are picked which will change the timing as well.  The big pro of programmable logic devices is that you can change the design of a device and use the same PCB.  A major con of programmable logic devices is that the propagation times change as the density changes for the application and compensation gates have to be added to insure stability and functionality of the device.

This update to the ITF section adds a single channel DMA controller that is shared as a Digital Logic Analyse for monitoring CPU BUS timing.  This becomes a very useful reuse design since not all designs will survive the reuse environment as we mentioned previously, only about 5% will be a true total Plug'N'Play reuse.  Experience has shown that FPGA and CPLD designs that incorporate the simplest of modifications have the risk of reduced performance, it is the nature of the beast.  We selected the larger of the MAX-II Logic Units to allow optimization and future additions if required.

Quartus 9.1 to Prime Lite 19.1 Timing simulation comparison:
The timing test was run on Release 9.1 and 19.1 the results were different for the same tests.  Release 19.1 has better routing optimization and also allows both functional and timing simulation that concur with both devices in the same family and speeds.  This is a good thing since we will be updating to release 19.1 when we update the custom equipment in the lab.  These are important issues for all in house equipment since we have talk to several labs some still running XP and are forced to remain on older versions.  An update will be presented as we continue to test and replace obsolete CPLD and FPGA devices

CPLD Register Identification
Since we neglected this because of the Reuse factor the thought was since the design matrix was already defined prior all that would have to be done is reassigning the bits for each register.  Well renaming the registers and bits did not turn out as expected and, oh by the way to make it clear; "It Very Seldom Does work as expected."  So, re-mapping the registers is required, that ok, however the complexities became clear that re-mapping lead to changing functions sequences and that lead to other changes and it soon became obvious when we started modifying the design the 50% mark of changes were present and the end is not clear.  At that point purely by experience it was decided to just start from scratch and layout the CPLD to fit the application with a few spare I/O pins for future growth.  In this reuse case it was fortunate that the redesign was recognized early before many man hours of troubleshooting and development were lost.

Final Note
Changing poor engineering habits are difficult however not impossible to correct.   Humans are very flexible they all have the ability of learning anything with applied effort, the only impasse is the mind set that if negative will defeat any attempt to grow and instill fear of learning.  The key is to acknowledge the initial behavior, no it will not change overnight - it took a while to become rooted.  Bringing the development behavior to the surface and acknowledging the behavior is the first step in this series to bring the development process to a winning level.   The expectations of this and other series on the blog is to encourage the behavioral changes as well as present a project that is useful for many applications.  Behavioral modifications is a personal and private process that takes time and requires trust within ones self.  

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

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


Reference Links:

ITF Selected Components

MAX-II EPM1270T144C5  Pin Assignment Template

BOM Spreadsheet and Component datasheets ZIP file

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

Intel®/Altera® Quartus Download 9.1 sp2 from Archives
Intel®/Altera® Quartus Lite 19.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


Previous Part 20 IoT Core Platform - Peripheral I/O Development - Peripheral Device Real World Testing -Continued(Nov  3rd, 2019)

 

IoT-Index


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-21 Peripheral I/O Design - Peripheral Devices- Real World Testing - (Mar 24, 2020)

For Website Link cut and paste this code:

<p><a href="https://www.basilnetworks.com/Blog/index.php?op=ViewArticle&articleId=28&blogId=1" target="_blank">BASIL Networks, PLLC - Internet of Things (IoT) -Security, Privacy, Safety-The Information Playground Part-21 Peripheral I/O Development:-<i>Real World Testing (Mar 24, &nbsp;2020)</i></a></p>

 

alt

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

3 Nov, 2019

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

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

"I can't change the direction of the wind, but I can adjust my sails to reach my destination" Jimmy Dean (August 10, 1928-June 13, 2010)

As we stated in past presentations in this series development costs are easily exceeded when the performance expectations and in that case performance requirements are not documented properly or the infamous "TBD".  This forces a direction change "AND" direction changes are commonly not listed as part of  performance expectations.  Sometimes the development "process" is faulty or just plain broken period.  The intent of this series in not to maintain the insanity of over budget development costs but to disrupt it in order to allow the creation of new habits that will give a solid foundation for engineering practices to be successful when starting a development project.

For the new designer that is taking on the learning of CPLD and FPGA design, "Each design completed is experience for the next lever of development."  There are only experiences and techniques that will bring you to the advanced level of applications.

IoT-Index Quick Links

Quick review to set the atmosphere for Part 20:
A lot of information was covered over the past 19 presentations of this series.  The progression from presenting an important explanation of safety, security and privacy of data, Internet basics from real basic to protocol complexities, conceptualizing a project development, presenting the need for secure accurate documentation as well storing that documentation where it is accessible during and after the product development cycle and of course the need to design in security and privacy during the conceptual development of a project.  

For review, the current Core Platform IoT development main focus is two fold, first an educational project development for the entrepreneurial mindset and the project applications of remote sensing and control incorporating safety, security and privacy over a wide range of peripherals including wireless.  This should be kept in mind since we will be designing in some redundancy for reliability and security.

The ITF development Project:
The ITF did create a change in direction, however did not change the desired results, this is not only common in development projects but is some cases required to meet the desired expectations.  The issues here are handling multiple projects, resources available and the changed timeline, just a short change in direction to complete the objective.  A validation that the real time product development process is far from being a linear process from conception to finished product.  

As we see this is a project within itself to show product development direction and expectations where resources are weighted and required for both product development, engineering performance testing and production.  The ADC-CHAN interface was selected since it was a "reuse" design and how it is to be modified to fit our application which would represent the standard peripheral interface to the IoT Core Platform CPU peripheral BUS requirements.  Initially presenting part of the Interface Test Fixture (ITF) to handle the remaining peripheral development for the series and continuing on with completing the  Interface Test Fixture (ITF) then go back to completing the ADC-CHAN Analog input design to insure the interface performance expectations.

OK, some information on re-use - With the ADC-CHAN design the reason it was easily presented was because it was a "Re-use" design so all the preliminary design work was completed.  Yes, this was selected with expectations to present the re-use with modifications vs the full design from scratch.  The full design process will be presented for CPLD#2 specifically from scratch to see what is involved with creating the design from start to finish and to review the reuse debate syndrome.  

Remember changing direction overnight does not mean changing goals our the final destination, it is just a better way to insure you will reach the desired destination.  In my years of exposure to the design arena as a designer,troubleshooter and mentor I have had the honor of experiencing innovative and passionate creators to realize that the creative thought process of an individual is not a linear step function, 1, 2, 3 ...N, probably because humans are not robots, that follow a preprogrammed set of processes as some may think of engineers.  The innovation of the human mind subconsciously is always performing scenarios to find the best solution for the task at hand and "developing habits along the way".

Over the past 40 plus years of being involved with product design, research, investigations and management so much has changed incorporating more tools to make manufacturing more controlled, design and development more accessible to all levels while increasing the level of knowledge for society adding more responsibility and accountability and freedom of innovation for individuals to take action and bring their ideas to fruition.

What we want to cover in Part 20:
In Part-16,17, 18 and 19 we addressed the issue of why we should consider testing of the peripherals (Proof of Design) PoD with a prototype build to insure when we interconnect several of the peripherals the throughput required for the applications will be met.  This allows the opportunity to change the development direction from the peripheral point of view if performance expectations become an issue. Developing a test methodology that will be used for testing peripherals for the platform keeping in mind peripheral throughput limitations. These are new habits being developed at a conscience mind set level that will connect to become the default critical thought process during development.  With that stated we will continue moving forward with detailing the Interface Test Fixture (ITF).

The design process in this part includes:

Updating the IPD project documentation for the ITF (Interface Test Fixture) to keep track of the development process, "Documentation is a living process during development", a good habit to make!  The reference for the ITF is the functional block diagram Figure 16.1

Lets Get Started:
Some questions answered from our readers
"What happen to the series?,  "It has been a few months from part 19, are you going to continue the series?  
To answer the above two questions - YES the series will continue.   We own and maintain several on-line servers as well as off-line servers here in the lab and we were in the process of upgrading them to the latest and greatest compliant requirements.  This took longer than planned, HHMMmm I think I said that about product development timing some where, well again we have added another first hand experience to our portfolio. Cool

Are there any sponsors for this series?
All devices for this project have been selected by their specifications and there are no sponsors for any of the components or the designs.  The possibility of sponsors for this project was put on the table for discussion and in order to keep this development purely on component merit the decision was made not to have any advertisement or sponsors for this project.  We also discussed private sponsorship from grant funds however the complexities and timing would have postponed the project for over a year while looking for grant.  We are still open for a grant if the opportunity arises.

Have you decided on any video presentations for this project?
We are still discussing this possibility of a YouTube channel which is  not our first choice or just put the videos directly on one of our servers as an educational series.  BASIL Networks website new addition is a gallery for presentations and videos that we will be posting at the beginning the new year.  For those interested please contact us using the BASIL Networks Contact Form for more information on when this will be available.  All the video creation, editing and processing videos are in place at this time and we are experimenting with several ways to clearly present hardware, firmware and software techniques through a video presentation.

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

Product design documentation is not only for the designer it is for those that will follow the design when the designer moves on to other projects.  Product development with documentation is the Knowledge Base for growth and the leverage for reuse.

  1. Interactive - by second nature without thought
  2. Flexibility - being able to record changes and additions in real time.  
  3. Development Traceability - development changes that effect several project are easily traced and recorded in each project.
  4. Multiple Project Tracking - This is where we are now - being able to start and track new projects that will eventually interact with the product development at hand, hence: the IoT Core Platform development project.
    So, the ITF Project name given is- Universal_Peripheral_ITF previously
    AND-- We are going to make some more changes, again---

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

[Selection_Menu] 

CPLD#2  I/O DataBUS Interface Registers Block Diagram:
OK, lets take the easy parts first, the Interface Data and Control Registers.  We will assign some tasks for these registers but hold off on assigning any bits or bit pattern until we actually implement then into the transfer sequence of the data.

From Figure 19.3 and Figure 19.4 the name of the registers have been assigned.  What we will create are the register bit widths, register functionality and data load path that defines the input side of the CPLD.  This will allow the flow control for the CPLD functionality.

OK, for those of you that have been following this series, a while back I stated that when you design a product you start from the output of what is desired and work toward the input to insure that you have all the necessary power to insure the transfer of power. This rule applies mainly for power supplies and power amplifiers since the drivers for each stage have to be capable of supplying power not just signal.  In the digital world there are only 1's and 0's and bits so we envision this approach a bit differently. Cool

The approach here is to insure there are enough input bits(pins) available to address all the required registers internal for the data transfer.  Since we defined the max on-board RAM to be 16Meg words, that dictates a 24 bit address.  The question is how do we want to address this data?  There are a few ways to do this, always start from address 0 to a final address specified by a counter register which would be the easiest of the implimentations.  However, looking forward much more control of the memory will be required when we get into the input data transfer mechanism.  Since we have designed these types of high speed interfaces over the years and have improved the process, (A polite way of saying that many shortcommings have been added to the experience port folio), the following register set for the memory data transfer is used as a starting point.

As a general preference rule for registers they are Read/Write type registers whenever possible.  Prior to 1981 before the initial PC was introduced peripherals with registers were always Read/Write.  The R/W gave a mechanism to test out specific logic for functionality. When the PC was introduced and the new associated controllers the read-only and write-only register sets were introduced.  Needless to say the complaints were compounded until some sort of reliability and multi-user programming methodology surfaced.  For software programmers a write only register is a Nightmare on Elm Street to keep track of in a multitasking environment.  OK back to the design.  Figure 20.0 shows the register breakdown of the on-board memory transfer section.

alt
Figure 20.0   CPLD #2 Register Functional Block Diagram

So, as we look at the register block diagram we see that the names have changed on the registers along with a different type of data transfer methodology.  Over the years designing data acquisition interface systems for updating and increasing ROI for capital equipment the following methodologies evolved allowing more control and flexibility to interfacing to the real world.  This modification is from the IBPD system that is approaching its ten year mark so we decided to present the new interface here that includes many of the features of a 16 bit digital logic analyzer as well as a straight digital I/O interface for testing peripherals.  The new additions are variable speed control via a DDS as well as data capture timing to measure propagation delays from BUS enable and data ready enable control lines.   Adding a pattern recognition to trigger data collection assists those oops it failed in the middle of a transfer bugs.

We also added a Start Address Register (SAR) and a Final Address Register (FAR) which allows addressing control for specified window of memory addresses for data transfer.  This type of feature is relatively common among more expensive data acquisition peripherals where multiple channels are designed in.  The SAR and FAR methodology compartmentalize the memory for multiple parameter testing of a peripheral by just programming the different parameters to the peripheral and it maintains the functional hardware setup with minimum changes.   We also added the clock timing control and the Programmed I/O functions that communicates with the Programmed Data I/O CPLD #1.   The timing and control for Enable and Data Ready lines incorporate a DDS AD9854 IC.  We used this chip for a few products several years ago and there are some other IC's that we will also look at however the 9854 has a dual DAC output that are phased controlled separately.  The price is in the USD $50 range for small quantities however it is one of the most versatile DDS IC on the market and will generate a clean 100MHz Sine, Triangle and Squarewave signals which incorporate two high speed DACs with a 14 bit phase control between the DACs.

The initial timing diagram for the memory transfer is still the same however there is added logic to handle the added features.  We will still start with the initial timing created in Figure 19.5   This timing will generally change as the CPLD#2 is designed and a full timing analysis is performed.  Propagation delays will change with addition to the CPLD when it is compiled.  This is one of the reasons that when using a dual CPLD design one CPLD will handle the critical timing part of a design and remains fixed in order to maintain performance.

CPLD#2 I/O Data BUS Register Setup Flow Diagram
The new memory data transfer changes also effect the way the CPLD is programmed as shown in the flow diagram in Figure 20.1 below.  The new additions require the setup of the ITF mode functions, Pattern recognition, speed of the transfer, default timing delays between enable and data available and a few other changes along the way. Performing a first pass design allows us to see how the internals are layed out and more importantly gives us an opportunity of fine tune the design for more flexibility.

alt
Figure 20.1   CPLD #2  Program Flow Diagram Memory Data Transfer

ITF CPLD#2 Direct Memory Access Controller
Now that we have the preliminary registers and flow diagram identified it is time to start getting to the detailed design.  The first step is to insure we have enough pins in the CPLD that will accommodate all the changes to the design.  Table 20.0 below identifies the number of I/O pins required for the ITF Memory controller.  From the previous parts we selected the MAX-II series 144 pin TQFP CPLD series since there are 116 I/O Pins available on the chip.  There are several sizes of the MAX-II 144 Pin TQFP available depending on the number of LE (Logic Elements or Logical Units) in the selected chip.  We will hold off in picking a specific chip until we do the design.  The Quartus IDE will identify the LE's required to complete the design during compilation.

Name Pins Description
Data I/O Bridge 8 Data Transfer to/from Laptop or Desktop
Device Select 8 Device Select, Chip Enable, Read Setup, Write Setup,  R/W Control
MAIN Clock 2 Main Clock - 200 MHz Differential input
Memory Address 24 External Memory Chip address lines up to 16 Meg Words
Memory Data Bus 16 External Memory Data Bus 16 bit word
Memory Control 8 External Memory Control Lines , R/W and enable lines
CPLD#1 Data Interconnect 16 Inter-communications between CPLD#1 and CPLD#2 16 bit Data
CPLD#1 Data Control 10 Inter-communications between CPLD#1 and CPLD#2 Control lines 8 bits
Aux Latched Byte Input 8 Aux latched input
Aux Direct Byte Input 8 Aux direct sense input
Aux Control 4 Aux Input Control
CPLD#2 Pins Required 112 Total I/O Pins Available=116 Spare pins = 4

Table 20.0  CPLD #2 I/O Pin Requirements

Since the Memory controller is contained within a single CPLD we can begin this CPLD design independently.  This is the main interconnect  to a Desktop or Laptop computer via the USB port to 16 bit bridge chip which we will cover in another part of the ITF development.  The changes in the memory controller came up during a discussion for other types of interface peripherals that may be used on the IoT Core Platform.  The addition of a security ID feature as well as digital pattern recognition at the bit level to start and end a data transfer process add flexibility for future development/

For the MAX-II CPLD design we will be using Quartus 9.1sp2 and 18.1 Prime.  At the time of this writing the Windows 10 release for 19.1 was not available.  This also gives the opportunity to compare the two.. The first issue found is the printer setup.  We have an HP Designjet T120 with the roll attachment for C and D size drawings.   This works great in Quartus 9.1 especially when p[rinting from ANSI B size to ANSI C and D sizes.   When we attempted to do the same in release 18.1 the page selection is totally out of sync with the sizes.. When we migrate from 9.1 to 18.1 the C size ends uyp to be a letter size even whern the default printer is the Designjet.  The size that works is Super C/A2 for release 18.1 which appears to be an Architectual-C.  The selection for C&D size are standard ANSI sheets and the ARCH sizes are larger, this is not a problem for the roll paper since it cuts to size.   I will download 19.1 for windows when it is available and runs some test on it for compatibility.   

OK, the CPLD#2 first pass is shown below in FIgure 20.2  and we find that it is possible to fit a lot of the control for the memory transfer into CPLD2 adding the extra features that gives us a 16 bit logic analyzer type memory buffer device as well as a other features for a programmed control 16 bit test fixture that includes a DMA control feature for CPLD #1.  

As a design preference it is a good idea to do a preliminary pin assignment layout of the chip to get a feel of how the PCB will handle the traces.  Pin assignment does effect the timing due to the internal matrix propagation times.   We have learned over the years that a good portion of system integration problems arise due to propagation delays and some type of timing problems with the interconnects of FPGA's, CPLD.s matrix and associated support IC's.  A preliminary layout and pin assignment will show the first pass at the propagation delays inside the CPLD / FPGA which gives the opportunity to change the design to accommodate the performance requirements.  There are ways to work around matrix timing issues and if we run into to them during development we will present them.  One of the ways is to use the next size up on the CPLD part number that has more Logic Elements and Pins if available.  These chips have a larger internal connection matrix and will allow more flexible optimization and shorter propagation delays.

IMAGE_CPLD2_DESIGN
Figure 20.2   CPLD #2  Design

Creating CPLD Pin Assignment Templates
OK, for the first time assigning pins for FPGA's and CPLD's my preference is to use a spreadsheet model that identifies the fixed pins then fill in the blanks.  All programmable Logic IC from all of the manufacturers have their own fixed pin assignments so this is a critical strategy to insure that the assignments do not conflict with fixed pins.  Below is the template for the MAX-II 1270 LE 144 TQFP model that we will be using here.  The design only uses about 50% of the Logic Units, however this allows for future assignments.  There is only a few spare pins, however we added an additional 16 pin input port just to make it easier if future modifications require more I/O pins.   Figure 20.3 and Figure 20.4 shows the blank spreadsheet pin assignments sued by number and by name.  There are a few signal names left in since we have performed similar tasks on several designs over the years.  You can download the Xcell spreadsheet and are free to use it.  The PCB schematic capture and footprints will be available when we get to that section of the series.  Click on each spreadsheet to see the assignments for the first pass of the CPLD.

IMAGE_CPLD-MAX-II-144Pin-xls-numscale.jpg
Figure 20.3  CPLD #2  MAX-II Pin Assignment by Number Design Template

 IMAGE_CPLD-MAX-II-144Pin-XLS-NameScale.jpg
Figure 20.4 CPLD #2  MAX-II Pin Assignment by Name Design Template

The file in Quartus the holds the pin assignments is a simple text file that can be opened by any text editor.  For this design it is "ITF-CPLD2.pin" and contains helpful information on how the unused pins and the I/O pins should be connected.  The file is organized by Pin Number 1-144 so it would be more efficient to fill in the By number spreadsheet first then fill in the by name template.  For the by name template I just input a clean spreadsheet and input the text file skipping all the previous lines up to pin one of the assignments.  Sorting them by pin name insures that all the pins are assigned.  Then just cut and past the name grouped into the By Name template spreadsheet.   The spreadsheet template for grouping the pins by name allows the designer to organize the layout of the PCB to fit the pin assignments and allow pin swapping to make the layout traces easier to route.

How to Obtain a Finished ITF:
Our plans when the ITF is finished, is to offer an ITF to the public that has many more features than the one being developed for this presentation.  We already have completed two different PoD products to get ready for manufacturing and offering custom development for contract manufacturing companies and the entrepreneur small company that want to setup a development test base for future and present development contracts.  Please use the BASIL Networks Contact Form to be put on a mailing list when we are ready to supply the manufacturing prints if you are interested in purchasing the entire system manufactured and tested.

[Selection_Menu]

SUMMARY:
OK, this is a lot to present in a single part as with most of the parts of this series as we dive deeper into the designs.  This update to the ITF section adds a single channel DMA controller as well as a Digital Logic Analyse for monitoring CPU BUS timing.  This becomes a very useful reuse design since not all designs will survive the reuse environment as we mentioned previously, only about 5% will be a true total Plug'N'Play reuse.  Experience has shown that FPGA and CPLD designs that incorporate the simplest of modifications have the risk of reduced performance, it is the nature of the beast.  We selected the larger of the MAX-II Logic Units to allow optimization and future additions if required.

The next part of this series will be addressing the timing for this CPLD #2.  The pin assignments will most likely change when we get into the PCB layout and we will come back to the timing performance as we change the pin assignment for a clean PCB layout.

CPLD#1 will cover all the serial hardware protocols we will be adding to the ITF.  The main serial protocols will be a very high speed serial protocol to address the various serial A/D converters and other serial sensing interface IC's.  We will be considering adding a TCP/IP Ethernet controller for the standard interface to the desktop or laptop or internal LAN network.  

Changing poor engineering habits are difficult however not impossible to correct.   Humans are very flexible they all have the ability of learning anything with applied effort, the only impasse is the mind set that if negative will defeat any attempt to grow and instill fear of learning.  The key is to acknowledge the initial behavior, no it will not change overnight - it took a while to become rooted.  Bringing the development behavior to the surface and acknowledging the behavior is the first step in this series to bring the development process to a winning level.   What this series will present by the successful development mind set to complete a Core IoT Platform development process as a winning process to insure success in any project development taken on.

BASIL Networks will be developing educational class room video modules to discuss engineering and project management principles by active example with hardware, software and lab experiments as we continue on with the series.  All hardware and software designed during this series will be available through our on-line video tutorials along with the class materials.

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

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


Part 21+ Preliminary Outline"Design the ITF: -Continued


Reference Links:

ITF Selected Components

MAX-II EPM1270T144C5  Pin Assignment Template

BOM Spreadsheet and Component datasheets ZIP file

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

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

Requirements Traceability Matrix  (RTM)
Project Management
Mezzanine Board

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

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

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


Previous Part 19 IoT Core Platform - Peripheral I/O Development - Peripheral Device Real World Testing -Continued(June 17, 2019)

Next Part 21 IoT Core Platform - Peripheral I/O Development - Peripheral Device Real World Testing -Continued(Mar 23rd, 2020)

 

IoT-Index


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-20 Peripheral I/O Design - Peripheral Devices- Real World Testing - (Nov 3, 2019)

For Website Link cut and paste this code:

<p><a href="https://www.basilnetworks.com/Blog/index.php?op=ViewArticle&articleId=26&blogId=1" target="_blank">BASIL Networks, PLLC - Internet of Things (IoT) -Security, Privacy, Safety-The Information Playground Part-20 Peripheral I/O Development:-<i>Real World Testing (Nov 3, &nbsp;2019)</i></a></p>

 

alt

Sal (JT) Tuzzo-Founder CEO/CTO BASIL Networks, PLLC.
Sal is available for client consultation and product development projects
any time by phone, E-Mail, directly through this sites Contact Form or
through LinkedIn


1 2 3 4 5 6 7 8 9 10 11  Next»
Copyright© 1990-2019 BASIL Networks, PLLC. All rights reserved
webmaster