Random Email

I just received a random email from some random person using some random gmail address, asking me for instructions on installing Xilinx ISE 7.1 on SuSE 10.1. So, I told him/her to install the latest version of ISE as there are many bugs in earlier versions. And I suggested following the instructions on the Xilinx website. Seeing that this person told me that he/she was a Linux noob, I suggested reading up on Linux or using Windows instead.

PS: I’ve just received a reply from this person. Seems like it was an Indian dude.

C++ Lab Problems

I spent the afternoon trying out the C++ Lab experiments today. I’ve finished 6 of the exercises and I’ve managed to catch a few potential problems:

  1. Emacs is configured with Syntax Highlighting disabled. I had to enable it each time I started Emacs. I don’t use any custom emacs startup scripts. So, this is a global problem.
  2. The XCC tool used as a compile/debug environment has a mouse-over focus. So, the cursor needs to be on the stdin/stdout area in order for the programme to receive user input. This is not stated in the handout.
  3. The instruction for accessing the Animation is inaccurate. It requires a little navigating before the actual link is found. This might confuse some students.
  4. The XCC environment hung a few times, while running the programme halfway (at random points). There may be a stability issue with the XCC.

UPDATE@2355: I finished up to exercise 8 and found a major problem.

  1. Missing GLUE library.

I’ve notified TL about it and he has taken action to fix the problems.

RedHat Server and ASIC Design Kit

I’ve just spoken to SJM, this afternoon, about the status of the RedHat Servers. It is something that they’re doing very soon and he told me that they should have it all set up in the next couple of days. Hopefully, I’ll be able to start looking at the design kit compatibilities asap.

He mentioned that he might want to try running it on the SuSE system to see if it works on it. If it does (there isn’t a real reason why it should not), then we may just run them off SuSE instead.

I’ve discovered something interesting called the ASIC Design Kit (ADK), which is a generic design kit provided by mentor under their Higher Education Programme. However, I’m not sure if we have access to the ADK as it is not listed directly on either the EUROPRACTICE site nor the RAL site.

From the ADK documentation, the target technologies are AMI 0.5m and 1.2m and TSMC 0.35m, 0.25m and 0.18m. This is good as we have direct access to the AMIS 0.5um backend design kit and we only need one foundry process for teaching purposes. From the ADK documentation, the kit provides:

  • Support for schematic, HDL or mixed schematic/HDL based designs
  • Synthesis support for Leonardo Spectrum
  • Pre-layout timing simulations with QuickSim and ModelSim (VHDL or Verilog)
  • Scan insertion support for DFTAdvisor
  • Automatic test pattern generation support for FastScan or FlexTest
  • Static timing analysis models for SST Velocity
  • Automatic place and route of designs using IC Station
  • Post-layout timing simulations with QuickSim, ModelSim (VHDL/Verilog), Mach TA, or Eldo
  • Support for Design Architect-IC

Therefore, it provides us with everything we need. Hopefully, we can get access to the ADK directly. This will solve our design kit problems forever as it is supported directly by Mentor. Otherwise, I will have to fall-back onto a backup plan for using the AMIS 0.5um design kit, which seems to be the most promising as it has support from front-to-back for the design flow.

Designing with Mentor and ADK

New VLSI Project

I spent some time thinking of a possible new design that might be suitable for the new VLSI project. As the students work in pairs, it would be easiest to get them to design some sort of communications device, with one designing the transmitter and the other the receiver. Then, they can put it all together at the end to see if it works. However, I have to keep in mind that most of these students would have had little exposure to hardware design, much less a VLSI one. This means that the project needs to be suitably easy for noobs, but is also extensible for the experienced few.

For this, I looked at some of the available open source designs on OpenCores and also some of the application notes from Xilinx. There is plenty of information out there, which is good. If we use examples from the Xilinx AppNotes, they come with some basic background info, which can be used for the handout. As it is quite often easier to design the transmitter than the receiver, I thought that we’ll just do this design for them. We can get the students to design the higher level parts of the stack.

DMH wants to keep the ring oscillator as part of the new design. This is simple enough to do as we can just use that as the internal clock source. To make things interesting, we could spec it so that the students either design different clocks for the RX and TX or use different phases of the clock for the RX and TX. Keeping this in mind, I came up with an idea for a simple communication project for the students.

General Project Idea

  • We spec different clocks for the receiver and transmitter that are non divisible by each other (e.g. 2MHz and 3MHz).
  • We provide complete physical layer designs, conforming to a standard protocol (e.g. RS232/SPI/I2C…).
  • We get them to complete the encoder/decoder. We provide them with partial code.
  • We get them to design an error detection scheme. This can be as robust as they want (e.g. Parity/CRC/Hamming…).

Assuming that the toolchain works automagically with the design kits, they can finish the front-end design in under 2 weeks, which leaves another 2 weeks for the back-end work. 2 weeks for the back-end work should be enough if the design kits work properly. The back-end work will involve substituting a single custom logic gate into the design and then putting the whole design through the automated tools.

Working Thru the C++ Labs

I’ve just received a reply from TL with regards to the C++ labs as he had just recently returned from holiday. This is August, the month when everyone except research students go off on holidays. He had promised to send me the relevant handouts/labnotes soon and he has sent them all to me via UMS. I guess that I’ll need to do the following:

  1. Ensure that the GCC toolchains still work.
  2. Ensure that the example code snippets are accurate.
  3. Ensure that the experiment instructions are clear.
  4. Familiarise myself with all the different experiments.

So, I will go through them one by one, before I go off on my break. I’d normally do this for any new experiment that I was introduced to anyway. It’s important to not only go through the motions but to also try to imagine the problems that students might face while doing it. Hopefully, with my experience in programming, it would not be too difficult to get through. I’m a little rusty on C++ as I’ve been mostly programming in low-level C for the last couple of years.

I’m a little confused at the idea of doing a C++ experiment though. I did not learn programming through formal methods. So, I’ve always been partial to the hack-n-slash school of thought. It would be interesting to see how they develop programming concepts through structured experiments. I guess that there will be experiments on assignments, control structures, loops and more interesting stuff like arrays, data structures, pointers and objects.

I look forward to trying them out.

Initial EUROPRACTICE Library Search

I’ve just spent a few hours doing a preliminary search of the available design libraries from EUROPRACTICE through the IMEC website. The following is a quick run down of the available foundry libraries:

  1. UMC – Mentor full custom back-end supported. Highly doubt that the FSC/VST standard cells are usable with Mentor.
  2. AMIS – Standard cells for Synopsys, Mentor back-end. Some unconfirmed successes getting it to work with Mentor.
  3. AMS – Standard cells for Synopsys/Cadence, Mentor back-end.
  4. TSMC – No publicly accessible info

So, this doesn’t bode too well. I might have to look at what standard libraries come with Precision Synthesis. I know that Leonardo Spectrum comes with a built-in standard cell library. But, Leonardo is already being EOL-ed. So, it doesn’t make sense to base a new project on a tool that will be dead soon. But, the bad news with Precision is that, at first glance, the tool is optimised for FPGA implementations and not for ASIC design. So, it might be necessary to use Leonardo after all.

I’ve just come across a potential solution. According to this website, it is possible to use the old AMIS ADK with the newer Mentor ICFlow2005. From a quick check of the Rutherford website, we have access to the older AMIS design kits and also access to the latest ICFlow2005.1 software. So, it might be possible to use a AMIS 0.35 or AMIS 0.50 um design kit standard cell library for designing with Mentor Graphics.

I’ve contacted SJM to find out the status of the Mentor installation on RedHat. He has yet to get back to me on it. Once it is set up, I will investigate the available built-in libraries in Mentor. There isn’t much else that I can do until this is done so that I can check out the tool chains and design kits for AMIS.

Search Acceleration – Introduction

My current PhD project is designing a hardware based search accelerator. Essentially, it will be like a graphics/audio co-processor, that will accelerate search algorithms. The surprising thing that I had encountered when I first started on this project more than 1 year ago, was that there is very little prior-art and literature on this matter. There is a lot of work done on hardware engines that sped up different things that would contribute to search, but there didn’t seem to be a comprehensive look at a new architecture to speed up search algorithms.

So, I thought, why not? We all know that search is an integral part of modern computing. It’s so integral that it is working itself downstream, from the back-end enterprise servers onto a user desktop today. Everyone can and will benefit from search acceleration. Therefore, it makes sense to try to design a processor architecture that has search in mind. There are several characteristics of search architectures that modern microprocessor architectures aren’t handling in the best method.

So, what are the major bottlenecks of running a search algorithm on a general purpose processor? Please keep in mind that I’m not a CompSci student. So, my knowledge in these matters is limited. However, I started my approach by looking at algorithms and data structures. After reading up on these topics, I have found some angles to attack the problem from.

  1. Processor Architecture
    General purpose processors (GPP) aren’t designed to handle algorithms quickly. This isn’t much of a discovery as everyone knows that the GPP isn’t optimised for specific applications but made to be a Jack of all trades. So, we can attack this problem by reducing the processor architecture and changing it into something more suited to handling algorithms.
  2. Memory Architecture
    All algorithms are N-bound operations. In the case of search algorithms, they are bound by the number of records that need to be parsed through. Due to limitations in memory technology, getting at these records may prove to be expensive. The method used to speed up memory access is caching. However, present day caches exploit temporal and spatial locality of reference. In the case of search algorithms, there isn’t much temporal locality as once a record has been parsed through, it is rarely needed again. So, we can attack this problem by designing a new cache architecture that takes structural locality into account.
  3. Search Operations
    Search operations perform some sort of comparison against a key and then do something if it matches the comparison criterion. In GPPs, these are typically implemented as conditional branch instructions. Even with the advances made in branch prediction technology, branching is still an expensive operation, whether in time or transistors. So, we can attack this problem by designing an architecture that reduces branches and makes branching cheap.

So, hopefully, by attacking the problem from these different angles, I would be able to design a processor architecture that is suitable for speeding up search algorithms. I’m not sure how much of a speed up I can hope to obtain. However, I’m hoping that it will more than double the search performance, when compared to a standard processor architecture. As with all my other processor designs, I plan to keep my design elegantly simple, small and fast. This is proving to be the problem.