ihsan Kehribar

OSX Based Minimal Verilog Simulation Toolchain

Wed, 14 Sep 2016 00:00:00 +0000

Hi All,

I recently tried to make myself more comfortable to Verilog world with minimum big software tools. Then, I created a small solution for myself and put it on to GitHub. Below, you can find the Readme file that I prepared for the codebase.

You can check the repository from https://github.com/kehribar/verilog-osx

About

One can say VHDL is second class citizen in open source software / hardware world. For example, IceStrom project only supports Verilog. Furthermore, easy to use and FOSS simulators like Icarus Verilog and Verilator also (in stable sense) only support Verilog.

Here you can find a bare-bones, OSX based Verilog simulation toolchain that I created using several different tools. Everything should be working under Linux as well (expect Scansion) though I haven’t tested yet.

Description

There are four different Verilog source files:

up_counter.v: 8bit unsigned up counter with clock, reset and enable inputs.
clken_gen.v: Clock enable pulse generator module with clock and reset inputs. Division ratio is parameterised.
top.v: Main top module that instantiates an up_counter and clken_gen module.
top_tb.v: Testbench module that instantiates the top module and feeds the neccessary test signals to the module.

If you want to change the example structure, see the Makefile then:

Change SRCS variable with new source file names …
Change TESTBENCH variable for another test bench file name …

Also, if you want to change the resulting waveform file:

Modify $dumpfile("top_tb.vcd"); line in the testbench code.

Commands

Hit make simulate to simulate the codebase and run the testbench using Icarus Verilog.
- Testbench’s output stream ($display, $monitor function outputs and also any error/log messages) directed to $TESTBENCHNAME_log.txt file to make later analysis more convenient.
Hit make lint to trigger linting using Verilator.
Hit make scansion to open up the Scansion application with recently created signal file. Only works under OSX.
Hit make gtkwave to open up the GTKWave application with recently created signal file. Not suggested for OSX.
Hit make clean to delete any generated files.

Prerequisites

Icarus Verilog
- Run brew install icarus-verilog to install on OSX system.
Verilator
- Even though verilator itself also supports simulation, I’m only using it to ‘lint’ the codebase for any syntax / logical errors.
- Run brew install verilator to install on OSX system.
GTKWave
- This application can be used to investigate .vcd waveform files. It was not very stable under OSX, so I moved on to other tool. Under Linux, this probably runs better.
- Run brew install gtkwave to install on OSX system.
Scansion
- This application is used to investigate .vcd waveform files. It is OSX only. It works much better (more stable) than gtkwave under OSX.
- Visit http://www.logicpoet.com/scansion/ webpage to download the application. Makefile assumes that you put the OSX executable under /Applications/ folder. You can change it if you want.
Sublime Text
- Sublime Text doesn’t support Verilog language as valid syntax extension. You should install https://packagecontrol.io/packages/Verilog package from package manager to have basic syntax coloring and couple of extra features for Verilog inside Sublime Text.
- You can, of course, use any other text editor as well. :)

Tips for analog waveform inspection

Scansion and GTKWave support visualising ports as analog waveforms. This feature is very useful in signal processing applications. Below you can see an example screenshot from Scansion:

Hit ⌘ + 2 to open Trace Inspector menu and select the desired signal. First, change the Style to Analog then adjust Height Scaling parameter to some high value to have bigger headroom in the display.

References

You should check these short but dense documents about Verilog:

“Summary of Synthesisable Verilog 2001”
- https://www.cl.cam.ac.uk/teaching/0910/ECAD+Arch/files/verilogcheatsheet.pdf
“Verilog Tips, Pitfalls to Avoid”
- http://retroactive.be/verilog_tips.pdf

Color image to 1bit dithered image

Mon, 05 Sep 2016 00:00:00 +0000

Hi all,

I’m trying to make myself more comfortable with blogging often. To do so, I wanted to publish a quick post about small project that I’ve done ~6 months ago. I’m basically revisiting the blog workflow while publishing this post :)

This is ‘Floyd-Steinberg’ dithering algorithm implementation in C++. Source code can be found at https://github.com/kehribar/Dithering-OpenCV

The algorithm is very useful if you have a black/white output capable only device (like thermal printers or monochrome displays) but want to have some sort of detailed image.

Results

References

See https://en.wikipedia.org/wiki/Floyd%E2%80%93Steinberg_dithering for additional details.

Polyphonic FM Synthesizer with STM32F031

Sun, 06 Dec 2015 14:00:00 +0000

Hi All,

I’ve built a playable, MIDI capable, polyphonic FM synthesizer using an 32bit ARM Cortex M0 microcontroller and an audio codec. This was a learning experience for me. You can find the finished form of the system in following two images.

Sound samples for the system can be found from the following two links.

https://soundcloud.com/ihsankehribar/wandering
https://soundcloud.com/ihsankehribar/daft-synth-stereo (Midi notes are coming from computer)

Please note that, there is no single tone for this device. Almost every parameter is tunable on the fly. In the future I may build a user interaface with buttons and knobs for this device but at the moment I’m just following change software - recompile - burn path for creating different sounds. Not much effective but works at the moment. :)

Earlier Work

Couple of months ago, I started this idea of creating a synthesizer with Atmel’s Xmega32E5 8bit microcontroller. You can find the code base for this project from here: https://github.com/kehribar/xmega_fm-synth

I hit some limitations with the Xmega system and wanted to go with an 32bit microcontroller. I ordered / designed couple of breakout boards and before moving on the final PCB form I prototyped the system.

Schematic

Final schematic is below. I’m going to explain the system part by part.

Microcontroller

I used an ARM Cortex M0 core STM32F031 for the project. Cortex M0 cores don’t have anything really extra than having a 32x32 hardware multiplier for DSP purposes. Cortex M3 and M4/M4F have specific DSP instructions and they would have been much more helpful for such a computational intensive task, but I just wanted to try what can be done with a low cost, entry level ARM chip. That specific microcontroller also have I2S and DMA module which is essential for this project.

For the system clock, I’m using the internal PLL to generate 48 MHz clock but I left optional XTAL footprint for future possible use.

R1,R2,R3 and R4 is used to slow down the edges of I2S signals to lower the high frequency noise a little bit. I put 49.9 ohms in the real circuit.

Audio Codec

This is 2channel, 24bits, 192kHz sampling frequency capable audio DAC from Cirrus Logic (previously Wolfson).

Best thing about this codec is, there is no need for DC blocking caps on the output. That means first of all no need for big bulky capacitors and secondly low frequency response of the output is much better since there will be no need for a high-pass filter to remove the DC level.

Also, this codec generates a negative bias voltage via internal charge pump and I’m tapping that voltage from the codec to power the opamp’s negative supply.

Output filter

Opamp that I used is MCP6002. It is not a low noise or audio grade opamp but it is rail to rail input/output and have enough bandwith and noise level for a just voltage follower.

This is a second order Sallen Key low pass filter followed by a single order passive low pass filter. Component values should have been properly selected for the best rejection curve, but I used 4.7 k for resistors and 4.7nF for the capacitors which gives roughly 7.3 kHz -3db point.

Power supply

LDO footprint is compatible with generic 5 pin SOT23 LDOs. Specifically I used Micrel MIC5317. There are two seperate regulators, one for the microcontroller, other for the codec + output filter. There are also ferrite beads at the input stage of the LDOs to filter out some high frequency noise as much as they can.

Midi interface

Optocoupler decouples the instrument ground with the controller board ground and eliminates possible ground loop issues. Also, optocoupler acts as a voltage level conversion between whatever MIDI keyboard sends and 3V3 microcontroller level.

In the v0.1 hardware, I mixed pin#4 and pin#5 of the connector. I patched it with knife + patch wires on the PCB. Easy mistake! :) Schematic is corrected.

Layout

I tried to follow Henry Ott’s advice for this layout. You should read his excellent article on the topic. http://www.hottconsultants.com/techtips/split-gnd-plane.html

I partioned the analog and digital portion of the layout seperate and connected two portions over a small bridge and passed every neccessary signal between two portions only on top of that bridge.

Sizewise, I just sticked to 5x5 cm rule of the low cost PCB fab houses though it could have been smaller if needed.

I used http://dirtypcbs.com/ for the PCB manufacturing.

Firmware

Toolchain

GitHub repository for the firmware is this: https://github.com/kehribar/stm32f031_template/tree/master/_synth This particular firmware is a part of my trial on creating a generic framework for STM32F031 microcontroller. You can check the base repository for other examples.

I used GCC compiler that I downloaded from http://launchpad.net/gcc-arm-embedded. Telling the Makefile where you unzipped the toolchain is enough. For the programmer, I used an STM32F4 Discovery board. After removing two jumper headers, that board acts like a generic ST Link v2 programmer. Calling make iterate on the command line just recompiles everything and flashes the board via OpenOCD under 10 seconds.

Sound synthesis

For a proper background on the topic, you can read about FM synthesis from the following links. I won’t be able to explain better :)

Here is my quick notes on the sound synthesis details of the system. You can also read the firmware to get more idea.

Sampling rate for the system is ~48 kHz.
All calculations are done with 16bit operations and all of the sounds are summed up to 24bit at the final stage with no loss of resolution.
System has 8 note polyphony at the moment. System can work with even more than that, but I limited it with 8 for the time being.
System has an LFO that modulates the amplitude of the sound at the final stage to create a tremolo like effect.
That amplitude changing LFO has also stereoPanning_offset variable that controls the automatic stereo panning effect between left and right channels.
There is one additional LFO to modulate the signal phase at a constant frequency with its own separate envelope to enrich to sound.
In total, there are three diffent envelopes, for output amplitude, fm modulation amount and lfo modulation amount for each sound with adjustable attack, decay, sustain and release parameters.
System is touch sensitive, meaning that maximum sound level and FM modulation amount changes with the velocity of the MIDI note.

DMA

DMA is used to transfer data from the microcontroller to codec. DMA on the STM32F031 isn’t double buffering capable so I had to trick the system to emulate a double buffering.

DMA itself has Transfer Complete and Half Complete interrupts. In the while(1) loop, I poll for these two interrupt flags and fill the first half or second half of a fixed lineer buffer based on which flag is set. As far as DMA concerns, it wraps to the begining of the array after it goes to end but in the mean time I change the content of the buffer without any data corruption problems thanks to the indication flags.

I2S

I2S peripheral of the SMT32F031 supports 24 bits transfers but it doesn’t play well with the DMA. For each sample, first you need to shift the data 8bits to left align it to 32bits. Second, you need to swap the higher 16bits and the lower 16bits in that variable. It is most probably due to how the DMA reads the memory. I learned that by some amount of debugging session.

The following code sample fixes a 24bit right aligned signed data to proper format such that when DMA reads it, actual outcome is what you expect. So much for a low cost microcontroller. :)

  
static inline int32_t convertDataForDma_24b(const int32_t data)
{      
  uint32_t result;
  uint32_t shiftedData;
  shiftedData = data << 8;
  result = (shiftedData & 0xFFFF0000) >> 16;
  result |= (shiftedData & 0x0000FFFF) << 16;
  return (int32_t)result;  
}

Downloads

You can download the Eagle files for this project from the following links.

Licence

This project is published under the terms of the GNU General Public License, version 3 licence.

Acknowledgement

Mutable Instruments community was really helpful to me during the development of this project.

Best,
ihsan.

Sensitive 'Loudness Detector'

Tue, 18 Aug 2015 21:33:00 +0000

Hi all,

I recently needed to build a sensitive ‘loudness detector’ for environment sound level sensing based project. I had the microphone part covered with my previous project [http://kehribar.me/hardware/electretAmplifier/] but level sensing part is left to do. I could use microcontroller to do the work in software but I wanted to have a relatively low power solution. Eventually, I had to build a single supply envelope detector.

Actually, that electret amplifier board itself have onboard diode + RC filter based passive envelope detector which can be used for level sensing purposes.

On the other hand, it doesn’t work good with low sound levels since the diode has ~0.6V drop. Standard solution is to use an op-amp as a super diode which all the examples on the web works quite OK if you have bipolar power supply rail. I wanted to have a single supply precision rectifier but couldn’t find too much information on the web, therefore I’m sharing the solution that I’ve come up with.

Output of the electret amplifier board sit around ~1V generated from [mic bias voltage / 2]. Initially I set the DC level of the input signal to VREF via R1 and C1. The two basically creates a high pass filter. Values are R1: 47k, C1: 0.1uF After the signal properly biased to the half supply, it is applied to the precision rectifier. I used regular 1N4148 for D1. Only difference from the existing solution is that R2 and C2 is going to VREF line instead of GND. R2 and C2 decides the responsiveness of the level detection. I used C2: 47uF and R2: ~100k to get a slow and steady response. One can play with the values of R2 and C2 to get much faster attack time.

I used half of MCP6002 to do the rectification and other half for generating VREF = VCC/2 voltage. I used R3,R4: 47k and C3: 10uF.

Overall circuit consumes around ~0.8 mA of current with the electret amplifier board as well. It can be considered as low power for a particular application. You can see the board in action from the video below.

video

I build the board on a perfboard which you can see the details below.

ihsan.

Adjustable DC voltage/current source

Thu, 21 May 2015 21:31:00 +0000

Hi all,

I’ve recently built an adjustable voltage and current source to test various hardware I build. Normally I was using a potentiometer to generate an adjustable voltage when I need but having a dedicated tool for the job seemed better.

I build this device by utilising a microcontroller, D/A converter, an op-amp + NPN transistor for constant current source and finally two optocouplers for serial communication.

R3: 1k

For the D/A converter, I used LTC1448 12bit DAC. It is relatively expensive for such a build but I had this IC as a sample for couple of years; therefore price wasn’t an issue. Moreover, since the battery voltage will vary with the milage and you can’t know the voltage value precisely I used an LM4040 zener reference to generate 2048 mV to the DAC. Therefore 1 LSB of the DAC output will correspond to 0.5 mV.

DAC has two channels and I used the second channel as constant current source. R1 is just there to limit the base current of the NPN transistor. Constant current is calculated as set_voltage/R2. I used 100 ohms for R1, and (10kohm fixed // 100kohm trimpot) as an R2. Trimpot is used to fine tune the output current. For op-amp I used a LTC1152 which can work down to 2.7 volts but it is not the greatest low-power op-amp with 3mA supply current. However, the op-amp is choper stabilised therefore it has very little low frequency noise which is useful for such application.

I used Attiny85 for microcontroller. Nothing specific about it, you can find the firmware here. I used Elm-Chan’s software serial library for basic I/O functionallity. I can set the voltage values over opto-isolated 9600 baud serial link and store them inside the microcontroller’s EEPROM.

R1: 4.7kohm R2: 470ohm R3: 470ohm R4: 4.7kohm

When power-up, microcontroller sets initial values to DAC, therefore I don’t need to configure the system each time I use. Also since I used optocouplers for isolation, I needed to invert TX & RX signals inside the firmware.

In conclusion,

System is not that accurate due to various reasons (small inaccuracy of the voltage reference, DC offset of the DAC and etc.) but it is highly stable. When I want to set the voltage channel to 250mV, I get around 250.45 mV of stable voltage out of it, which is enough for my needs.

Also for a much better adjustable voltage reference build, you can check Linear Technology App note 86 called A Standards Lab Grade 20-Bit DAC with 0.1ppm/°C Drift

ihsan.

ESP8266 + xmega32e5 - Wireless Temperature Sensor

Sun, 10 May 2015 20:35:00 +0000

Hi all,

Couple of months ago I built a wireless temperature sensor using my xmegaE5 breakout board and an ESP8266 wireless module.

Normally this type of task could be handled inside the ESP8266 chip entirely; but at the time I couldn’t create a decent toolchain setup and I went with using the module over AT commands via stock firmware.

It measures the ambient temperature using MCP9700 sensor and sends the data to Sparkfun’s phant.io server. I’m using imp.guru to visualize the data. You can find my data stream from this link. Also, you can find the latest complete xmegaE5 firmware for this project from this link.

When the microcontroller powers up, firmware checks the state of external push button. If the button is pushed, it goes to server mode; otherwise it continues with the client mode.

  
if(digitalRead(D,3) == LOW)
{
  server_mode();
}
else
{
  client_mode();
}

For server mode, device creates a predefined wifi network that others can join in. In this mode, client mode SSID settings and phant.io public/private key informations can be loaded into microcontroller’s EEPROM without any firmware modifications and without any external hardware required. For interactivity, xmegaE5 acts like a very basic web server that responds back to TCP messages coming from port 80. Let’s say the wifi module has 192.168.10.100 IP address in the server mode. Trying to browse to the following link …

http:\\192.168.10.100\s,fancy_ssid_name

… from a web browser, sets microcontroller to store the fancy_ssid_name as its SSID name for the client mode. SSID password, public/private keys for the data server also configured similarly.

For client mode, device tries to join the SSID with the information stored inside the EEPROM. Then, periodically reads the ADC, applies filter on the result and tries to send to Phant.io server with a particular private/public key stored inside EEPROM. If anything goes wrong in the process, like wifi being down or HTTP request taking so long, system makes a full reset to recover from it.

You can check the firmware for other details. I’m running this system on and off for about 5 months, and works OK without any major problems.

Notes:

There is an LM1117 LDO underneath the perfboard that generates a separate 3V3 rail only for the ESP8266 module from the 5V USB voltage. Onboard LDO of the xmega breakout board is not enough to power the wireless module properly.
There is an RGB led for status indication and I’m driving it with a timer driven software PWM since I didn’t use the proper dedicated compare output pins.
I also put a specific header for SPI flash IC and wrote a basic driver for it. Reason was to enable over-the-air programming support for the xmegaE5 chip. Since earlier I wrote a custom bootloader for xmegaE5 chip, firmware part wouldn’t be that hard but I couldn’t motivate myself enough to deal with proper cloud backend solution that can scale without any major issues.
Firmware uses a lot buffers at its current state and could be reduced significantly with proper tweaks.

Here you can find couple more shots of the prototype:

Hello World!

Sat, 09 May 2015 12:18:00 +0000

Hi all!

I started to use Jekyll based blogging system. Nothing fancy here yet. I normally use my other website for releasing finished projects but I’ll use this blog to release some unpolished prototypes.

Theme definitely needs a change, but done is better than perfect. I’ll probably tweak with the look of this site soon.

I’m using Github for hosting, and Atom editor for entries. I would normally used Sublime Text, but Jekyll plugin of the Atom worked better.

I’ll also leave this post with an image of Jim Williams’ “Living room thermometer”. Because, why not.

ihsan.

#####Image is taken from: http://www.edn.com/design/analog/4411017/3/Jim-Williams--The-light-side-and-classic-electronics-art-sculptures