AEMB Virtual Ethernet MAC Madness

An ethernet MAC is the device inside a computer that provides the interface to an ethernet network. An example open source ethernet MAC consumes about 2800 slices in an FPGA. My new AEMB design only uses up about 1500 slices. It doesn't seem very logical to integrate a MAC that is almost twice the size of a processor, in order to make it ethernet capable.

So, if someone is interested in building an embedded application with an ethernet connection, they can either:

1. Use an off-the-shelf ethernet MAC like the RTL81XX series of chips and stick it on the board. These come in a variety of bus interfaces to communicate with different processors. Then, they can write a low level software driver to drive this chip. The typical interface is either ISA (8-bit mode) or PCI (32-bit mode). There are a variety of vendors for these chips.
   
2. Integrate a MAC into their processor and interface it to a PHY. There are quite a few embedded processor coming onto the market today that integrate a single built in MAC. Even little 8-bit controllers from Microchip have built in ethernet capabilities. Everyone needs an Internet capable toaster. The programmer treats it in much the same way as any other built in device of the micro controller, and write software to control it.
   
3. Try to do something truly crazy, and implement a virtual MAC in software!

I've just been toying around with the idea of a virtual software MAC. I'm thinking of this in terms of using it with the AEMB. I can be quite certain that the AEMB can run at above 100MHz. This gives it about 50MIPS per thread. So, the question is simply, whether or not there is enough software power to implement a software MAC.

I started investigating a couple of different PHYs. I checked out the RTL8201 and LAN8700 chips. Regular PHY chips use the MII interface which is a defined standard (IEEE 802.3u). So, if a MAC (virtual or otherwise) conforms to this standard, it will be able to interface with most industry PHYs. So, reading the technical data-sheets, I find that the transfer interface is fairly simple. For a 10BaseT MII interface, the data is transferred in 4-bit nibbles at 2.5 MHz!

2.5MHz!

This is most certainly doable in software with a 50MIPS thread, if the software is written well and the hardware interface carefully defined. A 50MIPS thread can potentially bit-bang at a maximum rate of 12.5MHz. So, it seems that it is potentially possible to implement an entire ethernet chip in software! I'm so excited. Now, if I can only split myself into two so that one can work on this while the other works on my PhD!

AEMB Virtual Peripherals

I was just thinking about what to do with the extra thread on the new AEMB. I have tested it and compared the results with the old design. There were some minor bugs that have been utterly squashed. So, now both the old and new designs produce the same results. So, assuming that the old design works, the new one works as well!!

Then, I wrote some software to set up the threads. This took a bit of work but the result is a very elegant method that is independent of user programmes. I wrote a small bit of assembly that would configure the two hardware threads differently and then reboot the core so that the two threads can run independently, instead of in lock-step.

So, now that everything seems to work, I have been thinking of some applications for the core. As the core is targeted for embedded applications, I was just wondering what I could do with it. Then, the idea dawned on me: virtual peripherals!

Virtual peripherals used to be fairly common on certain embedded platforms as they weren't equipped with the necessary I/O devices. For example, it is possible to get a small micro to emulate multiple I2C/UART/SPI devices without actually wasting any extra silicon on actually integrating these devices into the system. This was particularly popular on the SX platform.

Oh my, this is going to blur the software-hardware boundary even further than it already is for me. Now, instead of integrating hardware blocks into the core, it will even be possible to emulate hardware blocks in software, on the second thread. Since the processor can run above 100MHz, it is possible to emulate a myriad host of devices.

AEMB Multi-Threaded Mania!

As I mentioned a few blogs ago, I have been toying around with ideas to improve my AEMB. I thought of increasing the pipeline stages and introducing fine-grained multi-threading (FGMT) into the processor. This is my first foray into building a MT processor. So, I wasn't really quite sure what to expect.

Anyway, I decided to try both things out, and the results have been extremely promising. In summary, I have managed to double the clock speed of the processor, while only consuming an extra 50% of resources. At the same time, the processor is now capable of executing two concurrent hardware threads. So, what this means in simple terms is:

1. Higher clock speeds translate into higher performance. The processor is capable of issuing one instruction each clock cycle. So, doubling the clock speed essentially doubles the instruction issue rate. The AEMB now distributes the clock cycles evenly between the two hardware threads. Assuming that it clocks at 100MHz, each thread will have 50MHz available.
   
2. Multi-threading increases efficiency. By multi-threading, the processor now has virtually no wasted clock cycles. This means that on top of doubling the instruction issue rate, it doesn't waste any of the useful clock cycles. On top of that, when dealing with slower devices, it doesn't need to sit around waiting as the second thread can continue to run while the first thread is servicing the slow device.

I've also made the design easily configurable. So, it is entirely possible to strip off some parts of it to further boost performance. For instance, the multipliers and barrel shifters can be removed. If space is an issue, one thread can be permanently disabled in hardware to reduce the space by 33%, while still keeping the high clock speed.

This may seem silly until you think about it a little. Assuming that the original consumed 1000 area units at 50 MHz and the new design consumes 1500 area units at 100 MHz, disabling a single thread will convert it back to 1000 area units but at 100 MHz. So, it can get the best of both worlds. However, it is still bound by the same restriction that only half the clock cycles can be used. But this gives it the added ability to interface with higher speed devices.

Seeing that the new core is able to perform better than the old design, even when it's utterly crippled, there isn't any real reason to keep the old design around much longer. I will notify my users of the new design and get them to migrate over to it as soon as possible. However, I will keep both designs in the repository for at least a few months, until I can be sure that all the kinks are ironed out with the new design.

Looks like the old design is going to be ignored from now on. I will freeze development on it and only perform minor bug fixes.

Improving the AEMB

My brain has been toying with some ideas for improving my existing 32-bit RISC processor design. At present, the processor has reached the stage of being very useful. It is being used in very unexpected ways by a very cool project. So, I have been thinking of the next direction for the chip. I will certainly solicit input from my users, but for now, I've been toying with a couple of themes.

Firstly, I have been toying with the idea of super pipelines, which is the concept of breaking up the existing pipeline into more shorter stages, in order to increase clock speed. The current AEMB has a 3-stage integer pipeline. It is certainly feasible to push this up to 5 stages, in a classic RISC configuration. This will not increase the speed of each individual instruction, but will increase throughput by having 5 instructions in flight at any one time.

Secondly, I have been toying with the idea of multi-threading, which is the concept of running multiple software processes concurrently, on a single core. This can effectively increase throughput on a core that has to handle a lot of I/O processes. It's quite normal for I/O processes to block, which is halting software processing, as it waits for the I/O to service. With multi-threaded processors, one thread can service the slow I/O, without blocking the other thread. However, this will require software applications to be specifically written to exploit it.

Both ideas will increase the amount of silicon area used for the chip. But hopefully, the increased speed and throughput will make up for it. I will have to balance all the considerations, as the target application for my processor is embedded applications, which typically emphasises size over speed. But it's an interesting way for keeping the design sexy and updated with recent trends.

So, just some ideas to toy with. Of course, I will already be adding L1 caches to the existing design to improve performance.

PS: I designed the logo using Inkscape and open source graphics. I've been playing with it recently. It's a superb drawing programme.

Swimming at the Form-Formless Interface

As I've mentioned earlier, I work mainly at the software-hardware interface. I used to believe that I could walk along the interface. But through my work, I have come to realise that it's more akin to swimming.

Working on pure software is easy, as everything is bounded by hardware. The designer has to come up with a solution to a problem, using whatever hardware is available. The first step usually involves selecting the right hardware for the job. Then, it's just a matter of coaxing the hardware to do the work by writing the right software for it. Although the task itself may be difficult, at least the problem is bound, so it's a finite problem.

Working on pure hardware is easy too. The designer has to design a solution to the problem, using whatever is physically available. The first step will involve selecting the right physical technology for the job. Then, it's just a matter of wiring everything up and turning on the power. Once more, although the task itself is difficult, the problem is bound.

Now, the difficulty with working at the software-hardware interface comes from the fact that I'm working at a shifty boundary. I can solve the problem, either in software or hardware. This grants me the added flexibility of either implementing the solution in software or hardware. But this flexibility comes at a cost, as I have to double my search efforts to search for solutions in both hardware and software spaces.

When the multiple solutions are found, I will then have to compare them. It's easier to compare apples and oranges. They're both fruit. With hardware and software solutions, one solution is physical, and the other isn't. The only common metric that can be used is time, i.e. which solution is faster. If speed was the only criterion, then it is simple. The trouble comes when I need to trade-off speed for something else.

Sigh. I think it's more like sinking at the interface now. It's as frustrating as it is exciting.

Beautiful, elegant code

I stumbled upon this guideline for clean HTML code, today. Although meant for HTML, the guidelines can apply to almost every form of structured language. This includes various kinds of code used for software programming, hardware design, document formatting and what nots. I'm currently designing my processors in Verilog, programming kernel code in C, writing up my thesis in LaTeX, drawing diagrams with GraphViz and DrawTiming. So, it's very important for me to keep a clean coding style in order to manage the project easily.

I regularly judged code quality by how ugly it is. My logic is this: if the coder does not even bother to make his/her code beautiful, the design itself cannot possibly be elegant. It doesn't matter how great the design is, if nobody else can appreciate it. I get to see more than my fair share of ugly code. I'm currently the demonstrator for 1A C++ labs. I cringe when I see most of their code. But I just bear in mind that for many of them, it's their first time, and learning the concepts is more important than having beautiful code. But, I still cringe, nonetheless.

I try my best to challenge them. But not many of them are willing to take it up. Most of them end up hating me and just ask some other demonstrator. The few who do take up the challenge, end up learning something. Programming is a task, best learned by doing. The others, will have trouble with their work for the next few years. These days, programming is a required skill. Everyone uses it. So, it's important to learn how to do it, and do it well.

Having beautiful, elegant, clean code is the first step to doing it well.

Updated AEMB

I've been getting a request from the company that is using the AEMB in their upcoming product, to add certain functionalities to the processor. I thought about it and realise that it would be difficult to tack on the functionality to the current processor. So, I decided to re-design the processor, with the capability to plug in future functionality.

There are also some minor bugs outstanding for the existing design, which are currently fixed by optimising the software. One bug was spotted by an engineer from a major EDA company that was using my processor for training purposes. It has been around for months but I haven't had the time to dig through the old design to fix it and it would be difficult for others to dig around as any minor design change may affect other parts of the processor.

There comes a point in a design where the amount of patchwork is so extensive that it's actually easier to start from scratch. So, my cleaned-up design also fixes the existing bugs (of which there were several). Since I was already familiar with the processor architecture, my effort at a clean redesign took only a day. I woke up early in the morning, popped everything into the rice cooker, and worked till I slept.

To my surprise, the new design worked without any problems. It even works without the unwieldy software optimisations. So, I'm more confident of the new design working than the old one. I will get the company to test the new design and I will gradually phase out the older design if no bugs are discovered.

The new design allows future functionality to be easily added. For the moment, I've included a barrel-shifter and a multiplier. In the test code, the one with the optional components and software optimisation runs at 1.6 times faster than the unoptimised one. However, the additional components slow down the processor by 1.14 times and increases the size by 1.09 times.

University Open Day

Today, there were so many kids running around the college and the department. It's our Open Day here. I had forgotten that I had volunteered to help out until I got a reminder email yesterday. So, here I am, in the picture, explaining the finer details of electrical machines to random kids.

We had a rather interesting set of gadgets to demonstrate. It starts with the basics of induction with currents producing magnetic fields that induce currents, which produces more magnetic fields. This was demonstrated with a setup involving a massive coil of wire wrapped around a steel core. Aluminum rings float when they are dropped into the core.

Then, we move onto the next setup, which has a series of single phase cores, that generate a magnetic field. By tossing sheets of aluminum onto the field, we can show levitation and how adding more sheets actually generate a stronger field.

Next, we bring in the concept of 3 phase current where we show a synchronous motor running. After that, we unwrap the motor onto a strip running on 3 phase current. This is used to illustrate the electromotive effect. The aluminum bar moves horizontally across the field when placed on top of it.

Finally, we deliver the coup de grace with the coolest display. We make a 3 phase tube with gradually increasing number of rings of each phase. This creates an increasing magnetic field, which results in an acceleration. Then we put in various materials into the tube, and fire it out onto a target. That's me, in the picture, describing one of the bullets that we fired out onto the target.

This was generally regarded as the coolest display in the room. You cannot beat an electrical cannon with anything else. I met another Malaysian, who was also demonstrating the same series of gadgets. It's surprising how small this world is. I was initially surprised that she didn't understand the principles involved. Then, I found out that she's actually a chemical engineer, but she's did a Masters is microelectronics and is now doing a PhD on CNT in our division.

PS. My hair is a mess. I need to cut it soon.

Illogical Loop

I'm currently overseeing about 30 third year engineers, for their projects, here in the Engineering Department. I'm overseeing two projects, a VLSI design and a data logger project. Today, I was totally drained by one particular student. If you're a third year B/F engineering student here, you will know who I am talking about.

I don't usually have problems with personality defects. As someone overseeing a student project, I will help a student with their problems as long as it is a legitimate problem. I try not to help people who ask me questions that they can figure out for themselves in 5 minutes. But, if the student is still struggling, I will ultimately help them. However, no one gets stuck once I tell them "it only takes 5 minutes to try it out." This is engineering, which is about doing. They are not going to learn anything if they don't try. The answer only becomes obvious when you try.

So, for the VLSI project, the only trouble student that I have is the rocker dude, whom shall remain nameless. He once jammed with me when I was practicing my drumming patterns for lion dance, in the lab. He has tattoos all over his arms and hair longer than most girls. I'm just quite glad that he has not shouted at me yet. I have once witnessed him shouting at Zern, who was just trying to help him out with an experiment. His only problem is that he has not been handing up reports. However, as long as he is learning something, that's the most important bit. I hate writing reports as well.

But, for my data logger project, I have this other student who is terribly long winded and incapable of understanding what is happening. I'm unfortunate enough to be one of his subject supervisors as well. I believe that he lives in an alternate dimension where the laws of physics work the way he thinks they work. Anyway, his group is the only group that has major problems with the project. When this particular student comes to me and tells me that something is wrong with the hardware or firmware or development environment or sample code, I sigh with exasperation and try my best contain myself. He fails to see the source of the problem.

But, I've been a little evil today. It was a long day. He came to me with problems during my off-day on Tuesday, while I was looking after the VLSI project. He told me that the firmware and software hangs. From his verbal description, I didn't see how there could be problems since he seemed to be doing the right thing. So, I told him that I would have to look at his code to help him. This morning at 9.00am, he promptly asked me to look at his code.

for (i=0; i=63; i++) { ....... }

Now, at first glance, anyone who is remotely familiar with C (or any other language) would be able to instantly spot the error in the loop. If you didn't, look again. Alright, you may think that it was just a typo. Well, if it happens once, it's a typo. When it happens twice, it might just be a careless mistake. When it happens more than that, you just have to suppress a laugh. There is no other way about it.

There were other problems with their project as well. They had happily made modifications to the sample code provided, without understanding what the original code did. As a result, they didn't know what they had changed, nor what was wrong with their current code. As diff wasn't available on Windows, I didn't want to spend ages tracing their errors. So, I just told them to replace their code with the original code, and make changes one step at a time. Voila, it magically works.

By 5.00pm, I had quite enough of him. His partner had quite enough of him by that time too. I was just ignoring him and telling him to keep quiet, in the nicest possible way. Good thing that I was only paid to stay till then. Another half hour with him and I would have blown my top. The lecturer in charge took a look at me, smiled knowingly and said, "Shawn, you look drained."

I didn't have any good comeback.

109.721 MHz Yeah!

Just a quickie post. I'd just updated my AEMB processor design today. I have received reports that a previous update of mine had broken something. Where the design was previously running at 70 MHz, it is now only running at 36 MHz or so. So, I thought I'd fix it. While I was in there, I thought that I'd optimise some things as well. All I can say now is, 109.721 MHz, baby!

As I had blogged about earlier, the design debuted at about 50k gates @ 40 MHz. Then, after some optimisation of the ALU and register file, I got it up to about 35k gates @ 70 MHz. The US company that's using it, is running their prototype system at 50 MHz for development. Today's update improved some aspects of the data path and the result is another 50% boost in performance at a discounted cost. It's now 33k gates @ 109.721 MHz!

Smaller, faster, cheaper and better! I'm seriously impressed! This baby of mine can really crunch numbers. And you want to know how long it took me to fix the bug? About 15 minutes to fix it and another 2 hours to verify it with the necessary tools. Cool, ain't it! Alright, I better stop blowing my own trumpet now. I'm just happy (:

PS. It took 2 hours because my computer is slow now. A new MacBook would make it much faster!

Easiest mailing list manager to use

I felt that it was time to run my own electronic mailing list. When I was about 16, I used to run a mailing list with about 300+ subscribers manually. It was a pain. So, I spent most of today setting up a mailing list manager on the website. It is not a trivial thing to do. There are a bunch of open source mailing list managers available but they're usually quite tightly coupled to a particular mail server. As mail servers are particularly complex pieces of software, instructions are not very clear on how to link a mailing list manager to my particular system setup.

However, after some googling, I found the easiest mailing list manager to set up. It is called mlmmj (Mailing Lists Made Joyful). Finding it took me almost a day but setting it up only took me about an hour. On the outside, it is similar to ezmlm. But unlike ezmlm, it is currently well maintained and very easy to use. It is not as powerful as ezmlm though it is good enough. It is now thoroughly integrated with the site forums so that any posts on the mailing list will automagically get archived on the website forums and vice versa, just like how YahooGroups does it.

I also did some basic site optimisations today. As I have limited memory on the private server that I'm using, I have to be thrifty on memory use. I had been getting out of memory errors several times. So, I trimmed down a bunch of stuff to get it to be nice. I will leave it to run for several weeks before deciding whether to upgrade to a more powerful server or to keep the current one. At the moment, it all feels fairly stable and useful.

My next plan is to build up a small community around my processor cores. For some reason, although I had released my aeMB microprocessor for several years, it's only recently that people had started to notice it. I have been getting quite a few queries on the core, over the last couple of weeks. So, I will try to build up a small community by inviting these people who're working with the core to join the mailing lists and submit bugs, patches and feature requests. This will hopefully turn my once slow traffic site into a medium traffic one.

As for the ae18, it doesn't seem quite as popular as the aeMB. So, I think that I will stop updating that core until enough people show some interest in it. There's probably little interest in it as it isn't quite as powerful a machine as the aeMB. When my new ae68 core is ready, I will probably release it on my website as well. This will provide people who're looking for a powerful processor, a choice between using the aeMB or the ae68, which are both 32-bits and capable of running Linux. The ae68 already has a community waiting for it. All I need to do is actually finish it.

Website hacked and other stuff.

I woke up this morning to find that I could not access my new website. All I got was a bunch of "Page Not Found" errors. Moreover, I could not login to the website via the web. So, it was all very interesting.

So, I logged in via SSH instead to see if anything was wrong. I checked to make sure that all the services were running. Then, I checked the logs to make sure that things were okay. That's when I noticed something fishy. Seems that someone had exploited a vulnerability in drupal to do some mischief.

There's this vulnerability in drupal that allows someone to launch this kind of denial-of-service attack by exploiting it's cache. It took me about half an hour to figure this out and flush the drupal cache manually. It was quite annoying.

This event taught me one lesson. Since I'm currently on a self-hosting package, I would also have to manage the website security myself. So, I should be careful about patching things up and ensuring that everything was running properly. Hmm, there are advantages and disadvantages to being on my former shared hosting plan. However, it's too late to change now. My old hosting contract has pretty much expired.

As for the rest of the day, I spent it pretty much trying to get my new FPGA board to work. I designed a simple counter and brought it through the whole tool chain just to verify that everything was working. Needless to say, I ran into trouble with the programmer and software. However, at the end of the day, I managed to get it working. The board is currently blinking LEDs in a count now. So, I know that it's working correctly. Sweet!

While trying to figure out how to get the board to work, I stumbled across another blog that had mentioned my chip. The blogger had downloaded my designs yesterday and had some complaints on it. So, I wrote to him to work things out. It seems that it wasn't a technical problem that he had with my design. He felt that my bit ordering system in descending order wasn't as having it in ascending order. We agreed that it's just a matter of preference and style. He was quite enthusiastic about using the processor in a future project. I wished him well.

My newest toy

I'm a very happy boy today. I had just received this in the mail. This is a useful FPGA development kit that I can use to test my future chip designs. This is my new toy that I will be playing with for a while.

The development kit was bought by the US company that is using my processor in their product. As I had gained a lot from using open source technology, I felt that I should give something back. Therefore, I had chosen to release my various chip designs under a liberal license. I also decided not to charge anything for the device. However, people who used the designs were welcome to send me any donations to support my work. [I openly solicit donations by placing a PayPal button on the webpage - Me!]

I know that there are many people out there who are using my design as the downloads number in the ten thousands. However, only some have chosen to contribute anything back. Previously, I had only received small sums of money through PayPal. Some chose to contribute back in kind, by submitting design patches and porting my design to other languages. This is the first time that someone actually bought me something useful. With this development board, I can run a whole gamut of hardware tests on my future designs.

The board comes with many cool features. It has a built in LCD display, external VGA output, audio ports, serial port, 10/100 ethernet port and a whole bunch of custom differential I/O pins (which can be used for USB and firewire and many other communications protocols). It also has 32Mb of SDRAM and more than 4Mb of flash memory on board for various applications. Essentially, I can prototype a full single board computer on the board. I might just build such a demo application, running Linux, in the future. [Remember that it wasn't so long ago that full fledged desktops had less resources than this little board - Me].

The most important thing isn't the board actually. It's the fact that there are people who have benefited from my designs and are willing to show their appreciation by sending me something useful. I've learned to ignore people who only bug me for help. [I'm not here to do your homework for you! - Me]. So, this will serve as a motivation to me to actually further improve my designs. I'm planning to build up an ecosystem around my processor designs. I've already taken the first step by setting up the appropriate project pages. I will later populate the documentation pages. Hopefully, this will result in more people adopting my design [and sending me more cool stuff! - Me].

UPDATE: Maybe I can build a tiny web-server application on the board or maybe an MP3 player that plays shoutcast streams. Both very fun and cool ideas. Of course, I'll only do this when I get the time to. Currently too busy with my work.

New private servers

I've not been blogging much over the last two days. Actually, I hadn't been doing anything else much except for setting up a new server. The existing hosting contract that I had with a Malaysian service provider is expiring this weekend. So, I made the decision to move things over to another hosting provider.

As a result of this move, I had to spend a significant amount of time setting up the new server. The new server uses a private server instead of the shared hosting plans that I used to use. Therefore, I had to set up a lot of stuff. In the end, these are the servers that I had set up.

• Postfix - for email delivery of the whole domain.
  
• Dovecot - for remote email retrieval using IMAP/POP3.
• MySQL - for the local database.
• LightTPD - for the web server.

And to facilitate remote administration, I had to set up a few other web based applications as well.

• PhpMyAdmin - for remote database administration.
• PostFixAdmin - for email domain administration.

And for front end interfaces, I chose to set up a few useful web applications as well.

• SquirrelMail - for a web mail interface.
• Drupal - for the main website content management system.

In the end, it took me about 2 days to get everything set up properly. Now all that's left is to populate the content. This, I will gradually do as I make more progress with my chip designs. I think that I will use my new website to handle my chip designs. I've set up the appropriate services for design releases as well as issue tracking.

The email works very well as well. I have only begun to realise how much spam actually gets sent to the server. Previously, all my email was handled by the service provider. Now that I'm doing it myself, I see all kinds of spam email being rejected by my mail server. Legitimate emails get through though. So, that's working fine for me.

Parallel processing headache

I'm having a splitting headache. It probably comes from the fact that I've been working on my AE68 for too long now. Processor design is an exercise in parallel processing. As the AE68 is capable of executing up to 6 instructions (with pipelining) at the same time, I need to keep track of all the instructions in flight. All that is giving me a splitting headache. My previous designs do not have as much ILP (Instruction Level Parallelism) as this beast. The AE18 executes 2 instructions at a time, while the AEMB executes 3 instructions at a time. Headache!!

I've been contemplating a while about writing a short series of blogs on hardware design. I'm wondering if it's a good idea as there aren't many instructional sites that show you how to do hardware design. Even the books are not sufficient and they often end up teaching you methods that cannot be implemented in the real world. I know that many of me readers don't read my technical blogs. So, if anyone is at all interested in reading about hardware design, please leave me some comments.

Anyway, I think that I'll stop working on the AE68 for a while. I'll get back to doing some other things (like work on my research project) instead and work on it over the weekends. I've already got most of the design down on paper. However, actually implementing it will probably take a little bit more time. Verification is going to be a nightmare and I'm already beginning to dread it. Well, hopefully, I'll be able to sign up a few volunteers to help me test and verify the processor, like for my previous designs.

*** Image shows a classic RISC pipeline with 5 instructions in-flight. ***

Hybrid 68K microprocessor

My blogging has been a little slow recently. The reason for it is that I've been working on another microprocessor design. This time around, I've chosen to design a 68K compatible microprocessor. However, instead of making a clone, I've made several improvements to it.

I'm calling my new design, the AE68, which is in-line with the names for my other processors. I've always wanted to work on an improved 68K clone. The 68K was my first foray into microprocessor design. I did it at a time when I had little knowledge of hardware design and totally no knowledge of computer architecture. I had to teach myself how to do it from scratch. Needless to say, the product was a monstrosity and only sort-of worked. However, it did bag me the top prize for final year projects as the examiners were suitably impressed with the effort.

Since then, I've always felt that this was one of my failures and I had to fix it. However, I've never quite had the time to work on it fully. Unlike my other designs, this one is a fairly difficult task to accomplish. To understand how complicated a design it is, the 68K was in direct competition with the prevailing Intel microprocessors (x86) in the past. PCs used x86 while Macs used 68K. Like the x86, it sported a CISC architecture, which is the reason for it's complexity. In fact, the 68K was technically superior to the x86. However, as we all know, it's marketing that matters and Intel won in that department. Furthermore, trying to figure out the workings of the processor without ever having used one before is difficult enough without having to sort through the minor differences between the many variants.

So, for the last two years or so, I've been toying with the design on-and-off. Recently, I've gotten a bout of inspiration and have mostly completed the design on paper. The next step would obviously be to actually implement the design and test it. The design that I ultimately came up with is a hybrid. Although it is instruction set compatible to the 68000, it is full 32-bit (ala 68020) and has a six-stage instruction pipeline (ala 68040). Also, most of the instructions should execute in a single clock cycle. This will hopefully bring a 24X increase in performance over the original 68K. The trade-off is that it will be a big processor, which sort of negates my preference for simple and clean designs. Once implemented and tested, I will try to optimise the design at a later date.

As for the users of this processor, there are already people waiting for me to finish it up. Like I've blogged previously here, I've actually been in contact with some of them regarding using this chip. They have been working on the board and software while waiting for me to finish up the chip design. Hopefully, this will be useful to them when it's finished. I'd be curious to see how well it works in the wild.

UPDATE@1550: Video of Steve Jobs launching the (then) new Apple Macs, which run on the 68000. Quote: "It eats 8088s for breakfast!". This is of course, in 1984, when I was barely even out of diapers. Extremely cheesy product launch!!

Engineers are happy when...

Engineers are happy when their designs work in the real world. It makes us happy to know that all the hard work that went into the design actually resulted in something useful. It make us happier if we know that it brings happiness to other people's lives. This is what makes engineers tick.

Today, I am happy. After returning from the play and downloading the photos, I checked my mailbox to find that I had an email from the US company that was interested in using my processor design, the aeMB. They had written to inform me that my design has been implemented and tested in hardware. And, it works without at hitch. It's communicating with the outside world via SPI and flashes a bunch of LEDs in programmed order. Every programmer knows that this is what's called a 'Hello World' design. Hallelujah! Break out the bubbly! As I had mentioned in a previous blog, I hadn't thoroughly tested the design as I do not have the resources to test it completely. My testing was limited to software simulation, which as every engineer knows, isn't quite the real thing. So, it makes me really happy to know that my design actually works in the wild. [Alright, I'm a geek. Worse, a PhD geek. I need to take my little pleasures whenever opportunity presents itself! - Me].

Now, for a little background about how they implemented it in hardware. For practically all digital chip design work, prototyping is accomplished using a device called a Field Programmable Gate Array (FPGA). Basically, this device has a lot of components in it that can be wired up into a complex design, like a microprocessor. It's the allocation of these resources and the custom wiring that allows it to function as a custom chip. Everyone uses it, including all the major chip design companies like Intel and others.

The reason that these devices are used is because it is too expensive to prototype a chip on a real fab. The cost for fabrication can literally run into tens of thousands of pounds for a few (about 20) prototype chips. [These figures are real, as I have to deal with these things as part of my PhD. - Me]. Once a chip is proven on an FPGA, it is functionally proven to work. So, the chip can be taken to the next stage, which is the ASIC design process.

For large companies like Intel, they can then do a fab run and tape out a bunch of test chips that they will then test to work out any kinks in the manufacturing process. Once a chip passes this stage of testing, it can practically be sold to the customer. However, this process costs a lot of money, and is really only an option for companies with wads of cash. I was once told by a director at Silterra (world's 9th largest fab situated in Kulim) that they wouldn't even bother talking to someone who doesn't have several million in the bank.

The alternative for smaller companies, is to use the FPGA as an end product instead of just a prototyping tool. For most intents and purposes, these FPGA function just like the real thing. They even look like real chips (they are real chips). So, smaller companies often use FPGA to ship out custom designed hardware to their end customers. In addition to cost savings, it also allows them to fix any bugs easily as these devices are programmable in the field. So, it's fairly safe to say that once a design works in an FPGA, the design works. If the company plans to manufacture an ASIC, they would need additional steps. If not, it is already market ready.

*** Picture is of a random device from Altera (one of the world's largest FPGA suppliers) ***

My 32-bit RISC core impresses me!

This may sound extremely cheesy, but I'm personally impressed by my own handiwork. Haha! I've been working on a 32-bit RISC microprocessor core, on and off, during my free time. The aeMB is a binary compatible clone of the Xilinx Microblaze processor. The core is currently among the Top 10 rated projects and is the #2 microprocessor in the list on OpenCores.

The project started several years ago when I was bumming around, while waiting for my graduation. I had just read the Hennessy & Patterson book and I was dying to try out some of the concepts illustrated in the book. So, I decided to design a RISC microprocessor. There were already open source clones of the SPARC, MIPS and ARM processors. So, I ended up selecting another popular processor instead. It is capable of running Linux and has an available GCC compiler. It's important to have an available GCC compiler as I can use that to compile software instead of having to write my own compiler from scratch.

I've recently made some massive updates to the core. There were several bugs that were discovered and many improvements made. As more people use the core, they end up uncovering bugs that I had not encountered. That's one of the benefits of open source. Some of the other improvements were made not because they were problems, but because other people had enquired about the capabilities. So, I thought that I would just throw it in if it didn't take up too much effort.

The reason that I had continued to work on the core was because some 3rd party had decided to use it in their upcoming product. If no one was using the core, I wouldn't have bothered to continue working on it. I managed to hand optimise the design to squeeze out an additional 50% speed improvement while reducing the resource consumption by about 40%. It currently uses up 34k gates @ 70 MHz on a Spartan3. That's fairly impressive, if I do say so myself.

However, I had never really stressed out the core. So, I can never guarantee the operation of the core. Just this morning, I updated the C test code using some open source numerical (Fibonacci, Euclidean, Newton-Rhapson) algorithms that I had found. The C code is compiled using GCC compiler, which is fairly standard. I had fully expected the tests to fail but they passed without much problem. This totally surprised me as I had never tested the core out as extensively before.

The new tests that I had included stressed the core out in many ways. It includes recursion and iteration, goto, modulo arithmetic, multiplication and division, floating-point arithmetic, type conversion (integer to float) and pointer operation. There really isn't much else that a microprocessor needs to do. With this battery of tests that the core now passes, I'm quite happy to say that it's working surprisingly well.

There is only one other thing to work on with the core, and that is interrupt support. I had originally included some basic interrupt support, but it introduced control hazards into the pipeline that I had not expected. It screwed things up if a branch instruction was already in the pipeline. There is a simple fix that I can implement quickly, but it isn't elegant enough. So, I'm going to think on the solution for a while more.