uHMCU – Alpha 0.1

After a pretty large redesign, I can now safely say that the uHMCU is in alpha stage! I’ve ironed out most of the bugs for my USART module and can now both send and receive data. I tested it up to 115200 baud with the USB <-> USART bridge on my FPGA board and after writing a simple program, was able to send a character from my computer, have it read by the uHMCU and have the uHMCU send back to the computer. There must still be a bug or two because theoretically, I should be able to send a string byte after byte from my serial console and have the uHMCU send it back but this doesn’t work as I can only send single bytes and receive single bytes back.

termite
USART Byte bouncing – Yup, I did send hikim…

Synthesis
Currently, with a GPIO (not fully wired), one timer, one USART and one 7 segment driver, I can synthesize my microcontroller using up:

  • 2093/6272 (33%) – Total Logic Elements
    1788/6272 (29%) – Total combinational functions
    907/6272 (14%) – Dedicated logic registers
  • 33/92 (36%) – Total pins
  • 30720/276480 (11%) – Total memory bits

I’ve not implemented any PLLs or multipliers though including a multiply instruction would be possible.

On the 85C slow model, frequencies of 75.07MHz can be achieved and with the slow 0C model, 80.16MHz can be achieved.Other than memory access and jumps, most instructions take 1 cycle meaning if I had an infinite program of summing two variables, I could achieve 1MIPS/MHz, wahoo!

As a side note, including a single cycle multiply instruction reduces the maximum frequency of the 85C slow model to 62.64MHz!

Interrupts
Obviously no microcontroller is complete without the addition of an interrupt function. One change I have made to the uHMCU instruction set is expanding the STK function. As well as changing whether addresses are pushed to the stack or not, this instruction can also be used to store the location of an ISR. An ISR in this case is merely the address of a function defined in assembly. It is therefore a good idea to call the STK instruction with the address of your ISR right at the top of your program. Currently, it will take a maximum of 5 cycles to jump to the ISR upon the rising edge of the interrupt signal (worst case being at the start of a memory operation – 2 cycles + the 3 cycles to perform a jump) excluding any context storage and loading. The current location of the PC is stored on the PC stack so upon leaving the ISR, the processor will return to the instruction after the one executed prior to the interrupt.

Currently, I’ve not written an interrupt controller. I’m thinking of going down the same kind of idea as a PIC which would involve having a memory mapped interrupt controller. This controller would have all peripheral interrupt lines going into it, along with a register to allow enabling and disabling of these interrupts. Interrupts are cleared by writing to the peripherals themselves causing the peripherals line to be de-asserted.

7 Segment controller
One useful addition is a 7 segment controller. My FPGA board features a 4×7 segment LED allowing the display of 16bit numbers in hex (0x0000 to 0xFFFF). I’ve not implemented the decimal point LEDs so only digits 0 to F can be displayed.

As with all my peripherals, the 7 segment controller is memory mapped and features the registers:

  • CTRL – Control register, currently only contains a single bit to enable/disable the display
  • SEG1 to SEG4 – Registers storing the value to be shown on the display. Only the bottom 4 bits are used. For further space saving, all of the segment values could be packed into a single register! The issue there of course being more effort required to write to the segments.

The 7 Segment display is refreshed relatively slowly with each segment being refreshed 82us, giving a total refresh time for the total display of 328us. This is obviously not a big deal because you wouldn’t be able to see it anyway!

P1010980.JPGRunning a simple count program

P1010981.JPGThe count advances!

For the above test program, a pretty inefficient implementation was used. One register contained the count and this count was copied into a secondary register. The secondary register was then shifted down and AND’d with 0xF (15), then written to the correct register. Realistically, the AND’ing isn’t required as only the bottom 4 bits are used by the controller but I thought I’d do it for completeness. The uHMCU shift instructions only shift by 1 value meaning for a shift right by 12, 12 single shift instructions are required. This negates the need for a barrel shifter at the expense of higher program code usage. Finally, a loop of 60000 decrements and jumps is executed. This is so the counter doesn’t increment too fast and can be see by the human eye!

Code listing:

stk 0
jmp ‘begin

‘begin
str ra 1
rtm ra SEG7_CTRL
str ra 0

jmp ‘loop

‘loop
alg inc ra

alg equ rb ra
str rc 15
alg and rb rb rc
rtm rb SEG7_SEG1

alg equ rb ra
alg lsr rb
alg lsr rb
alg lsr rb
alg lsr rb
alg and rb rb rc
rtm rb SEG7_SEG2

alg equ rb ra
alg lsr rb
alg lsr rb
alg lsr rb
alg lsr rb
alg lsr rb
alg lsr rb
alg lsr rb
alg lsr rb
alg and rb rb rc
rtm rb SEG7_SEG3

alg equ rb ra
alg lsr rb
alg lsr rb
alg lsr rb
alg lsr rb
alg lsr rb
alg lsr rb
alg lsr rb
alg lsr rb
alg lsr rb
alg lsr rb
alg lsr rb
alg lsr rb
alg and rb rb rc
rtm rb SEG7_SEG4

str rb 60000
jmp ‘decl

‘decl
alg dec rb
jpz rb ‘loop
jmp ‘decl

Further peripherals
As of yet, I’ve not got round to implementing a VGA controller. My methodology is likely to be a single bit display (pixel on or pixel off only) to save on memory space. For a standard 800×600 sized display, this should use up 60000 bits of RAM of which more than enough is available with this FPGA!

I’ve not really thought of what further peripherals I’d like to implement as of yet. There are a couple of auxiliary ones, for example an SDRAM controller though I’ve not come across any test programs that need more RAM than I already have. Another consideration could be a complex ALU unit, one that could calculate trigonometric values, along with useful things like multiplications and divisions. Once again, I’ve not really found a use for this unit yet so that’s in the pipeline (haha.) at the moment too.

My board features a couple of on-board peripherals which I could communicate with through I2C or SPI so making either of these two controllers could probably be an interesting task though all of my peripherals as of late generally only seem to work in 1 mode (e.g. my USART module only working with 8N1 signalling). One of the on-board peripherals is an ADC which I think would be quite a good one to interface as I could then have a go at some painful and slow DSP!

I’m happy to have got my microcontroller at least to the alpha stage! Given the choice of the uHMCU and other implementations, I would obviously choose others due to being written by people much more fluent in VHDL than myself though its been a really good learning exercise as I’ve managed to learn about what constitutes a useful ISA, along with writing an assembler and implementing a microcontroller system as a whole!

Keep tuned for further updates!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s