First week of class on the course of Interconnected and Embedded Systems.
Course layout
In this current course, the topics are laid out in 4 main categories
- Intra-chip communications: How are ICs structured, how do embedded processors work, intra-chip data buses, and Network onChip — NoC
- Reliability: Data encryption, and Error detection and correction
- Wired Communications: UART, SPI, I2C, CAN, LIN
- Wireless Communications: Bluetooth, LoRa, Wifi, Sensor networks
For the first quarter we will see topics on computer design and architecture, VHDL and some notions of how data moves inside a processor. Very low level abstraction.
Tip
The teacher always seeks to correct some attitudes or bad practices he’s seen some student do in some projects. The way he helps is is with a situation.
Imagine you are testing UART communication between two MCUs, how do you proceed to rule out what is malfunctioning. For most people a first instinct is to check your code, maybe you made a simple easy to fix mistake, then if that’s not it you would check your connections, which should always be the first thing you do specially if you are working with sensitive devices. In my class a lot of people said that physically attach one of the Tx pins and connect them to an LED, some other option included similar stuff with buttons and such. Using LEDs and buttons are could be a way to check if you haven’t burned your microcontroller but not a good way to check communications. If you find your self in an electronics lab, a standard practice you should do in order to confirm, test or check wired communications should be a logic analyzer, check that the baud rates are consistent and that you are sending what you are intending to send.
Now imagine that you’ve validated with a logic analyzer and you can’t quite make your application run as you want, the next step should be to use an oscilloscope. Using an oscilloscope will allow you to check accurately of the input and output voltage levels and in accordance to what each MCU needs.
Introduction to VHDL
In a previous article, I wrote about how and why you would use VHDL, if you haven’t read it it’s ok, the only thing you should know is that VHDL is a Hardware Description Language, In science it’s always a treat for me when the name of things actually makes sense with what you are doing. Note that this isn’t a programming language per se. A programming language is turned from human readable code to assembler and later to hexadecimal code that the processor can read and execute.
In VHDL the written code is used by a software like Vivado, to describe how you want hardware to be structured. You can used some commands to say I want an AND operation done after this OR operations in a certain manner. We usually use logic tables, that’s what we are doing, describing how the hardware should be constructed, now from this piece of information it can sound tempting to say “oh, I use VHDL to say how I want my logic gates arranged” and that is only a half truth because the FPGA doesn’t necessarily have logic gates nor it uses them like Legos.
A FPGA is conformed by LUTs or look up tables, in essence it uses the logic tables result of our digital circuits of state machines in order to tell a given LUT what the inputs and outputs should be. In a later article we will see that Vivado does allows us to see the abstractions of our circuit based on logic gates, but don’t let that fool you an FPGA does’t consists of logic gates, they are made of LUTs.
