BASIL_NETWORKS


Designed & Made
in America (DMA)

ABOUTABOUTPRODUCTSSERVICESSUPPORTCONTACTARTICLESBLOG
BASIL Networks BN'B

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-19

saltuzzo | 17 June, 2019 11:26

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

"If you keep on doing what you've always done, you will keep on getting what you've always gotten" Traced to Henry Ford (July 30, 1863-Apr 7, 1947) and Tony Robbins (Feb 29, 1960 - age 59)

There have been many paraphrases of this much used quote - the one that stand out along side of it is "Insanity is doing the same thing over and over again and expecting different results" You would probably say to yourself that is an Albert Einstein quote, and you would probably be close to right since there have been no known documents by Albert Einstein containing this quote.  However, it was researched and "vetted" by Michael Becker an editor at the Bozeman Daily Chronicle.  The earliest written form was found in- Rita Mae Brown  (Nov 28, 1944 -Age 74) Quote from 1983 fictional book "Sudden Death" character Jane Fulton  In fact this and similar quotes are referenced in so many places, show that misattribution like these happen often.

OK, what is the point here?
Many years experience in product design and troubleshooter in several fields of interest these above misquoted phrases seams to always appear before and during outside help is brought in.  OK, here we go making a broad statement, All, yes, "All" companies at one time or another face a situation that in-house talent cannot solve the issues at hand, or to put it another way, the current in-house talented resources are not recognized within the organizations culture.  On many occasions when called to troubleshoot or assist with an issue that a client is having difficulty in solving, these or very similar quotes seem to always pop up, "This is how we always do it! or "managements process guideline require we follow these parameters", and so, on and on.

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.

Quick Links

Quick review to set the atmosphere for Part 19:
A lot of information was covered over the past 18 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:
As we see this is a project within itself to show product development direction and expectations easily shows how 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.

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.  

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 19:
In Part-16,17,and 18 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:

  • Creating hardware flow diagrams, Hardware timing diagrams,
  • Using the IDE to design the CPLD#2 - Part 20
  • Creating a CPLD#2 schematic Symbol - Part 20

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

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.  

Some questions answered from our readers

Lets Get Started:

Some questions answered from our readers
I received a very good request from a reader.  "Why not link all the references to the original part throughout the series calling up the specific part  for review when referenced.?"  Well the answer for me is simple - that would require a lot of maintenance and the probability of broken links are way too great.  The other issue is that each of the blogs are referenced from a database and references would have to load the entire blog to display. It is easier and efficient to just create a new link for the part in question than to jump back into a previous part where some browsers may or may not open it in a new page or tab.  This will help the reader to focus on the current task at hand with less diversion.

Another question is why five different JTAG isolation channels?  This initial design is for assembly houses that will address many different types of programmable devices.  For those that only work on one type of programmable logic a single channel; is fine and if another type is required an simple changing of the JTAG wires will accommodate various types of programmers.  Here in the lab we have a separate desktop PC that is used primarily for CPLD and FPGA programming connected to the development network.  This is easily maintained since the logic manufacturers provide separate stand alone programmers.

From our experiences connecting and reconnecting and of course the occasional oops did not want that to happen, it is easier and cost effected to separate these functions for manufacturer of the CPLD's and other programmable logic.  We will add a single channel JTAG isolation channel for those that only need a single channel.  Remember this is an educational series and you have the ability to add value to any design that you decide to undertake. This series will walk you through step by step of product development..

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".

OK another change of direction that we are considering- we have a complete video creation system here in the lab that we have been encouraged to use for this series.  We have created videos for client business presentations but have not created on to put on-line, so we are discussing putting this series in video format that will have much more content and technology sharing along with encouragement and stories from other entrepreneurs and how they handled different situations.   For those interested please contact us using the BASIL Networks Contact Form for more information on when this will be available.

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 at times from one development task to another a tracking system should meet the following requirements.

  1. Interactive - by second nature without thought
  2. Flexibility - being able to record changes and additions in real time.  During development changes in one project can easily effect another project.
  3. Multiple Project Tracking - This is where we are now - being able to start and track new projects that will eventually interact with the product development at hand, hence: the IoT Core Platform development project.
    So, 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. :)

[Selection_Menu] 

The ITF BUS interface Block Diagram:
We will be designing the I/O peripheral BUS architecture interface in this part as shown in Figure 17.2 Functional Block Diagram of the ITF Data I/O Section which is a redesign from several years ago when 208 pin MAX CPLDs were available from Altera® and have been discontinued and no longer available.  We could possibly get these 208 pin CPLD's on the surplus market however it is not recommended since they will not be readily available in time. Since we address and emphasize longevity for this design the components should be up to date and not on any Not-Recommended-For-New-Designs list.  The 144 pin is readily available and up to date for this so we will design using two of them to perform the required functions for the ITF.  As stated before we use the TQFP package since they can be easily installed and removed manually if repairs are required.

There are a few ways to approach a CPLD design from scratch two of the more common ways are explained below along with the approach this series will use.;

Just build the logic block diagram with everything you want on it then try and compile the design.  This will generally tell you if there are enough pins available for the design.  From there just start putting blocks of the design on another CPLD and shuffle the blocks until you get the results desired.  This method forces the designer to address sections of the I/O in blocks that are manageable with the understanding they will be moved around.  This will develop a solid sense of Modular Design Methodology (MDM) and by the nature of the habit will allow you to move design blocks to fit the application.  This approach does take a few years prior experience in designing I/O.  BASIL Networks does have a library of designs and part of this design will be incorporated into the ITF.  

A more systematic approach is to identify all the pin assignments first then design each section around the pin assignments.  This approach is a bit more structured which by the way still requires a single designer and not meant to be split to several designers.  Since this is an educational series we will take the more difficult structured approach and incorporate it into the IPD System to develop good engineering habits.  The previous way does not allow for detailed documentation on the ITF and is generally created after the design.  Humor - there are some that think this is possible and expect a working device as well.

Since we are using multiple devices the challenge becomes how do we separate the functions for everything to fit and insure the performance.  We have separated the ITF functions in Part 17 and we will take each section and obtain a pin requirement for each. Figure 19.1 shows the entire CPLD Block Interaction.

IMAGE_ITF_CPLD_INTERFACE_BLOCK_scaled.jpg
Figure 19.1   Functional CPLD Interface Block Diagram of the ITF

CPLD#1 ITF BUS Data I/O:
Peripheral I/O BUS to CPLD#2 Data Transfer:

This CPLD is assigned the task of communicating with the several attached Parallel I/O devices and passing the data to CPLD #2   As we design this CPLD we will probably expect to add a few functions along the way as most designers do to make testing easier.  This isolation is more cumbersome than difficult part of the design since it entails a set of digital isolators.  Since the Isolation is separate from the CPLD we will design the CPLD first then the Isolation section.  The pin assignments will he assigned after the Isolation interface is designed to simplify the layout of the design.

  • ITF BUS Data = 16 Inputs, 16 Outputs, 6 Enables - Total 38 pins
  • ITF BUS Control = 8 control, 6 Enables - Total 14 pins
  • ITF BUS CPLD to CPLD  16 Mem Data Inputs, 16 Mem Data Outputs,  8 Memory Sync&Control  - Total  40 Pins
  • Total I/O Pins for CPLD#1 = 38+14+40 = 92 of 116.

CPLD#2 Memory Data and Real World Interface:
Transferring Peripheral Data From CPLD#1 To Desktop

This CPLD is assigned the task of collecting the data from CPLD#1 and communications with the desktop for analysis.  This is shown in Figures 17.4 the On-Board Memory Buffer and Figure 17.5 USB Interconnect BUS.  

  • ITF BUS CPLD to CPLD  16 Mem Data In, 16 Mem Data Out,  8 Mem Sync&Control  - Total  40 Pins
  • Memory Address 24 pins
  • Memory Data 16 pins
  • Memory Control 2 pins
  • Real World I/O USB Connection  20 pins
  • Total I/O Pins for CPLD#2 = 40+24+16+2+20 = 102 of 116

It appears that both CPLDs have a few pins to spare while maintaining CPLD to CPLD communications and control for the remaining serial I/O functions like SPI and I2C control.  To start we will create a functional block diagram of each CPLD and the functions they have to perform to communicate with the controlling desktop.  For this design we will look at a simple USB 2.0 interface as we discussed in previous parts of the series.  If a high level of security is required for all test equipment we have security level test interfaces that will comply to compartmental security standards.  We will separate the functions as we create the documentation for each CPLD.

CPLD-2 Functional Block Diagram:
Starting with CPLD#2 mainly because it is the CPLD that will not be reprogrammed or extra functions added once designed.  This is due to the fact that changing high speed  CPLD/FPGA design changes propagation delays and may render the device non functional after compilation, A risk that many development managers take and find that the cost exceeds the expectations exponentially.

CPLD-2 is the main CPLD for the ITF because it incorporates a high speed I/O memory buffer for testing performance of peripherals.  The features of this I/O memory buffer has to be fully programmable to transfer data at a selected transfer rate to test performance limits of attached peripherals.  To handle this we will incorporate a fixed TCXO along with a programmable DDS chip to control the actual transfer rate.  The use of the DDS allows us to add programmable phase shift to the synchronous edge of the reference frequency in order to test performance.  This changes the ITF CPLD#2 functional block diagram to add the DDS Timing Control.  Figure 19.2 shows the new functional block diagram for CPLD#2.  As shown the design changes as the development continues and the documentation of the process is required to handle these unexpected changes.

This is the CPLD that will remain fixed and not re-programmed to add other functionality.  CPLD#1 is the general interface CPLD and will have the flexibility to add functions as needed.  This is the leverage of adding a second CPLD to the test fixture gives for future enhancements without redesigning the entire fixture.

Oops - there are still free cells and the design worked before we added this small change - just a few gates and a small register.  Many of us in the FPGA/CPLD design field realize that when you start adding features to FPGAs/CPLDs many strange things start to happen, like the propagation delays change and registers seem to be missing bits at certain bit weighting, these are the pitfalls that few talk about and many are misinformed of the consequences of just adding another couple of bit control to a working design.  These phenomenon have been observed in the lab during development many times and at time manual tracing of the FPGA design has to be performed patiently to fix the problem.  It would be more cost effective to just keep a working fixed design in a CPLD/FPGA and adding a second CPLD/.FPGA for the expansion of features that may be required later.


Figure 19.2  CPLD #2 Functional Diagram I/O Assignment Blocks

OK, to start the development process for CPLD#2 we would list the functions that this CPLD is required to perform.  Since this CPLD requires a couple of external components, high speed RAM a USB interface for the real world.  If we require full security in communicating with the ITF we would use a RJ45 network connection with another embedded processor with encryption for this.  Oh wait - that is one of the applications for this IoT Core Platform .  Characterization of these components are required to insure the CPLD is interfaced to give the expected performance and of course a timing analysis to see if the speeds and interface requirements match the CPLD's I/O characteristics.

CPLD#2 Proposed Timing Diagram similar to the one we created for the AD_CHAN peripheral except this one will have to work at 20ns throughputs.  The expectation of this memory buffer is to allow peripherals attached to be able to transfer peripheral data to the memory buffer without CPU intervention.  This is essentially a Direct Memory Access (DMA) controller for any peripheral connected.  In our embedded IoT Peripheral platform was defined back in Figure 12.3 IoT Platform Interface Function Segment Mapping That shows a DMA controller interface to memory.  This interface is very high speed and may be added to the IoT Platform as well if the application requires multiple peripheral and multiple high speed buffers.

The ITF Direct Memory Access Controller:
In some Embedded Processors the a DMA controller is already implemented and only allow DMA transfers to selected peripherals that are embedded on the chip however, having total control to select the peripherals gives far more flexibility through a separate DMA controller.  This DMA implementation on the ITF is a good exercise to understand the creation of timing diagrams before jumping into the fun stuff designing logic circuits On-The-Fly. The DMA sequence of operations has two sections, the setup and the data transfer on request.

Sequence Setup for CPLD Memory Buffer Controller

  • Clear Selected Channel in Channel Register
  • Set DMA Count Register Count -1
  • Set Starting Memory Address Register (MAR) in Buffer Memory
  • Enable DMA Requests From Selected Channel
  • Wait for DMA Request

On DMA Request

  • At DMA Req - Read Data In to Memory Address
  • Increment Memory Address
  • If Last Count - Output Term Count
  • Stop DMA Res For Selected Channel

The Art of Timing Diagram Creation:
There are many approaches to designing digital system, the approach here is to develop a timing diagram of the critical data paths used in the CPLD that include the DMA control data transfer from the Data Bus and a control interface for the real world data transfers.  Lets design this timing diagram from scratch to understand the process of developing a timing diagram since we just presented a timing diagram in the AD-CHAN peripheral without showing the actual mindset and process to develop it.

Some basic logic skills are required to visualize the sequence data flow while creating the timing diagram.  For those beginning in the field this process becomes second nature with digital design experience is acquired and being exposed to system integration techniques of peripherals and devices, it just takes some practice and a little bit of imagination.

The ITF memory buffer is essentially a Direct Memory Access (DMA) controller, so to start lets look at a single channel DMA controller for now.  From the Sequence Setup for CPLD Memory Buffer Controller above we see the setup registers that are required.  

Required Data Transfer Features:

  • Multiple periodic timed data transfers both Data In and Data Out - this implies that MAR would have increment capabilities.
  • Programmable data transfer counter to control the number of transfers of a Block.
  • Programmable clocked Data Out - implies a frequency generator (DDS)
  • Multiple repeat block data transfers both data in and data out - This looping requires the MAR to be reloaded which infers a Starting Address Register (SAR) in implemented.  

From the above sentence we deduce that some type of end count register/counter has to be implemented to keep track of the number of transfers in order to maintain a specified SAR and memory block to control data transfers.  We will call this the Terminal Count Register (TCR), also some type of a latch to be set when the TCR ends its count.  A current Status Register would be good to monitor the state of the transfers without disrupting the transfer, so a Current Status Register (CSR).  The Status Register is a bit oriented register made up of one bit registers that are controlled (Set/Reset) individually to identify the current status of the device.  

OK, Lets Group The Given Registers:
    SAR - Starting Address Register Holding Register
    MAR - Current Memory Address Register
    TCR - Transfer Count Register
    DDS - Data Transfer Clock
    CSR - Current Status Register

How Much Static RAM to design in?  The High Speed Static RAM selected has asynchronous read/write times of 10ns and 20ns. The selection here is the 2 Meg x16 10ns chip IS61WV204816BLL-10TLI and is readily available.  If we want to add up to four of these chips for a total of eight Meg x 16 bits the MAD and the SAR have to be wide enough to handle the memory.  For an eight Meg address we would require a 23 bit register for the MAR, SAR and the TCR.  If we wanted more than one channel we would have to repeat this set for each channel, so as we see this can easily use up CPLD resources so we will keep it at a single channel at this time.

Now imagine the data flow process and what sequence of synchronized pulses have to happen for each data transfer.  We also have to be able to setup the DMA controller prior to any data transfers to insure the data will be placed in memory where directed.  The next section is how the data transfers are actually performed at high speed what digital lines have to be used to perform the operation successfully.  This is where the control, pulse, strobe and status lines of the timing diagram are transcribed on the timing diagram.  

In order to insure all memory data transfers a top level clock is used to synchronize the data transfer and should be at least 2x faster than the memory R/W time.   That leaves us with 10ns=100MHz for the memory and 5ns=200MHz clock frequency to latch the data for transfer.  

Creating a Timing Diagram:
OK - as a rule for the lab during development all timing diagrams are drawn on a B-Size (11x17 landscape) format.  This has been found to be the best fit for these typed of developments.  The Lab software for this is Visio and has been implemented several years before Microsoft acquired Visio Corporation in Jan 2000.  The best part of this is all the old drawing using Visio 5.0 before the acquisition work fine so the transition was seamless.

Some CPLD register characteristics - in the lab it has been tested that a 4ns device has the capability of loading a register in less than 10ns so as a default to start the design and create timing diagrams 10ns is a fair place to start.  When you compile and assign pins to the CPLD the IDE will perform a timing analysis to show the actual load requirements.  The propagation delays for wired vertical meshes adds about 1.5ns per connection so we added at least 15ns between load pulses in order to avoid data bus and general trace routing.  The time between load pulses depends on the embedded processor selected and the nesting level to the actual I/O device that controls the setup sequence.  Since this is from a USB bridge the time is generally quite long in comparison these times are for sequence of operation only.

CPLD#2 Setup Timing Diagram:
Starting off simple to understand the mindset of developing timing diagrams, all technology that contains a process flow will have a time line and a flow diagram to represent it.  "The initial mindset of innovation is to be able to understand what drives the flow of a process."

The first part the CPLD#2 design is to create a hardware flow diagram of what functions exists to obtain the expected performance.  Figure 19.3 shows the hardware data flow diagram  for CPLD#2  DMA function.

IMAGE_Flow_SetupTD1
Figure 19.3  CPLD #2 Register Setup Flow Process Timing Diagram #1 Section

Figure 19.4 shows the timing diagram created from hardware flow diagram in 19.3.  This process is an industrial preferred design process, however there are many companies and engineers that just jump into a design and brute force there way until they get something that sort of works.  Granted this is a more time consuming process however, many of the performance expectation are more clear using this method as well as allowing a team approach to allow changes.

IMAGE_DMA_SETUP_TIMING_DIAGRAM
Figure 19.4  CPLD #2 Register Setup Timing Diagram #1 Section

The timing diagram in Figure 19.3 above is a separate part of the CPLD design which are the setup registers for the DMA controller.  The 200MHz clock is not part of the setup sequence it is only there as a reference starting point. The Data IO BUS is the real world BUS from the USB bridge to the CPLD and is the main connection bridge to the desktop or laptop that is being used to control the ITF.

Creating the Memory Data Transfer Timing:
OK, reviewing the Required Data Transfer Features: above we will start to create a sequence or a data path for the timing diagram.  The end results are the capability to transfer data to/from memory directly without any processor intervention other than the initial setup, simple.  The Clock Timing IC has to have the capability of generating 10ns pulses.  The initial thought was to use a simple counter with a 200MHz clock input that will count down and put a Terminal Count pulse when it is at zero, however that would only give us a divide by 2n and as "n" increases the delta between steps increases and fine tuning the performance is not possible.  The solution is to change the design a bit and add a DDS IC which allows programmable 32 bit frequency tuning and 14 bit programmable phase control to measure performance accurately.  The DDS IC that will handle all the frequency requirements is Analog Devices® AD9954 a 400 MSPS 14bit DDS capable of 32 bit frequency tuning and 14 bit programmable phase offset.  This will handle all the current and future requirements for Digital I/O that we would encounter for this generation.  Also this would require a stable frequency reference source which is the Analog Devices®  AD9540 a 655 MHz Low Jitter Clock Generator that is tuned for 400 MHz clock for the DDS that has a 48 bit frequency tuning word resolution and a 14 bit programmable phase offset.  This chip does require an additional 8 pins for all the features, 4 for the serial communications and three bits for up to eight separate clock profiles.  Both chips use a SPI interface communications only consumes a few pins and is controlled through the USB interface directly which is also supported by the IBPD System which makes it easy to setup.  As we see Designs just seem to grow from the initial idea or concept as the details are presented, flexibility is mandatory in order to obtain the performance required from the ITF.  

The Status & Control Register (CSR)
The CSR allows the user to Arm, Set Direction, Terminate Scan, Manually Start Scan and other functions that will be defined as we create the timing diagram.  The CSR is the last register to access to arm the DMA controller and the first to end the scan as a starting point.  The actual bits could be assigned at this point to aid in the timing diagram.  The table below is a typical eight bit status register assignments for this type of device.  The remaining bits assignments will be added as the design continues.

BIT NAME Read [R]
Write [W
]
DESCRIPTION
7 BUSY R/W [R]  - 0 = Disarmed Off,  1 - BUSY - DMA Armed
[W] - 0 = Clear-Disarm DMA,  1 = Arm DMA for transfer On
6     TBD
5     TBD
4 DIR R/W 0 = Data Transfer From Memory To  Device
1 = Data Transfer From Device To Memory
3     TBD
2 Ref Profile
MSB
R/W

Status Register Control Group for DDS Reference Clock
2  1  0 Bits
1  1  1   = Reference Clock Profile 7
1  1  0   = Reference Clock Profile 6
1  0  1   = Reference Clock Profile 5
1  0  0   = Reference Clock Profile 4
0  1  1   = Reference Clock Profile 3
0  1  0   = Reference Clock Profile 2
0  0  1   = Reference Clock Profile 1
0  0  0   = Reference Clock Profile 0

1   R/W
0 Ref Profile
LSB
R/W

OK, Building the timing diagram in sections, the next part of the diagram that will be presented is the actual data transfer from the BUS to the Memory.  OK, Adding the DDS and DMA with high speed RAM is a little different than the ADC-CHAN design since we do not have any A/D conversion time to consider.  The process flow diagram is straight forward for this process and is shown below, the data is immediately transferred during the transfer command strobe and the data is on the BUS during that pulse.

IMAGE_DMA_TIMING_CPLD2
Figure 19.5  CPLD #2  DMA Flow Process Timing Diagram #1 Section

From the hardware flow diagram shown in Figure 195 we will create the first pass of the timing diagram that was used to create the DMA section of the CPLD#2 Design.  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.

IMAGE_MEMXFER_TIMING_DIAG
Figure 19.5  CPLD #2 DMA Timing Diagram #1 Section

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 this part and by now we see why the design reuse has merit on stable designs.  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.  

Changing poor engineering habits are difficult however not impossible to correct.  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 of the Core IoT Platform is 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 for questions to separate them from getting lost in the general comments for each blog presentation.  For all specific design request or contracts pleas feel free to contact us.


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

  • Adding the ITF USB interface to the Real World
  • Designing CPLD#2 functions with the IDE
  • Assigning CPLD#2 pin numbers for Schematic Symbol
  • Creating the Schematic for the ITF
  • Creating the PCB Layout for the ITF
  • PCB FAB drawings and ordering the ITF for this series.
  • A link to download the IBPD System for this series.
  • A review or the Successive Approximation algorithm used in A/D conversion
  • Testing the A/D peripheral.
  • Adding other features to the A/D Channel while finishing the PoD schematics for the ITF
  • And more ....

Reference Links:

ITF Selected Components

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 18 IoT Core Platform - Peripheral I/O Development - Peripheral Device Real World Testing -Continued(Apr 25, 2019)


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

For Website Link cut and paste this code:

<p><a href="https://www.basilnetworks.com/Blog/index.php?op=ViewArticle&articleId=20&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 (June 17, &nbsp;2019)</i></a></p>


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

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

saltuzzo | 25 April, 2019 13:43

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

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

IoT_Main_Index

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Selection_Menu]            [Top_Menu]

 

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

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

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

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

Signal Name Description Pin Assignment Change
TCK  Clock Signal [Data Input] 5
TDI  Data To Device [Data Input] 3
TDO  Data From Device [Data Output] 2
TMS  JTAG machine Stat Control (Enable) [Data Input] 4
Vcc  Vcc Device Power Active Level 1
GND  Signal Ground 6,7

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

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

Signal Name Altera 10 Pin Xilinx 14 Pin Cypress  10 Pin Atmel 10 Pin Lattice 10 Pin ITF  SATA 7 Pin
TCk - In 1 6 4 1 1 5
TDI - In 9 10 8 9 5 3
TDO - Out 3 8 6 3 7 2
TMS - In 5 4 2 5 3 4
Vcc 4 2 1 4 6 1
GND 2, 10 3, 5, 7, 9, 11, 13 3, 5, 7, 9 2, 10 2, 4, 8 6,7

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

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

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

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

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

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

IMAGE_ITF-ISP_SINGLE_CHANNEL
Figure 18.0a   Single Isolated ISP Programmer Interface

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

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

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

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

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

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

IMAGE_ISP_SINGLE_CHAN
Figure 18.0b   Single Isolated ISP Programmer Interface

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

IMAGE_ITF_ISP_SCHEMATIC.JPG
Figure 18.1   Schematic Diagram of the Isolated ISP Programmer Interface

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

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

[Selection_Menu]            [Top_Menu]

IMAGE_PCB_ASM
Figure 18.2   ITF ISP  PCB Assembly Layout

IMAGE_ITF_PCB_TOP
Figure 18.3   ITF ISP  PCB TOP Etch Layout

IMAGE_ITF_PCB_BOTTOM
Figure 18.4   ITF ISP  PCB BOTTOM Etch Layout

IMAGE_ITF_FAB
Figure 18.5    ITF ISP  PCB FAB Drawing

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

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

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

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

Item# DataSheet (Spreadsheet Local File Link) Device Unit Cost
Quantity Solder Profile Device Unit Cost / 100
Reference Designator Package Type Device Unit Cost / 1000
Schematic Value Cad Footprint Required Quantity /100 Build
Description Component Unit Cost Required Quantity /1000 Build
Manufacturer Part Number Component Unit Cost / 100 Buy Total Cost /100 Build
Manufacturer Component Unit Cost / 1000 Buy Total Cost /1000 Build
Distributor Minimum Purchase Required / Component  
Distributor Part Number Lead Time Weeks  

Table 18.2   Common BOM Spreadsheet Column Names

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

IMAGE_ITF_ISP_ISOLATION_BOM
Figure 18.6   ITF   ISP Isolation Interface BOM Spreadsheet

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

[Selection_Menu]            [Top_Menu]

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

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

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

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

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

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


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

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

Reference Links for Part 17:

ITF Selected Components

BOM Spreadsheet and Component datasheets ZIP file

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

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

Requirements Traceability Matrix  (RTM)
Project Management
Mezzanine Board

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

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

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

 


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

 

IoT_Main_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-17 Peripheral I/O Design - Peripheral Devices- Real World Testing - (Mar 15, 2019)

 

For Website Link cut and paste this code:

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


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  Next»
 
Powered by LifeType - Design by BalearWeb
Copyright© 1990-2018 BASIL Networks, PLLC. All rights reserved
webmaster