Tag: Open Source

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.

Do we need Open Source Hardware?

A recent article at Linux.Com asks a question of whether we need an Open Source Hardware License (OSHL). It wonders if current Open Source Software (OSS) licenses might suffice. There is also an issue raised on whether we actually need Open Source Hardware (OSH) at all. Coming from that particular source, I find it weird that they would even think such things, much less voicing it like that.

There is no doubt that OSS licenses have proven good for software. However, hardware is quite another issue. The article says that most hardware designs are software anyway. VHDL and Verilog are examples of hardware design languages that are semantically similar to software programming languages. This though, points out a big difference between the software and hardware people. There is a slight lack of understanding of hardware by the software people.

Hardware can certainly be designed in VHDL and Verilog. However, that’s only one way of representing hardware. Hardware can also be designed in schematics. Now, you may wonder who still designs stuff in schematics. In this age of multi-million gate designs, how could anyone still design stuff in schematics. The answer is, the hardware people still do. This is done everyday by people working on analogue and mixed-signal designs. There is currently no way of describing analogue designs in a “language” such as VHDL or Verilog. Although both of these languages feature analogue extensions, these extensions are currently only suitable for simulation and not synthesis. Analogue design is still very much an art form. So, a lot of work is still done in drawings. So, such works could by extension, be conveyed under copyright law. That is rightly so, but the OSS licenses aren’t necessarily applicable to drawings.

Derivative works are another issue altogether. In OSS licenses, they usually mention terms for binary or compiled versions of the code. But for hardware, it isn’t exactly compiled into binary form. Some may argue that synthesis is akin to a compilation process. That is true, as synthesis does convert design descriptions into a hardware representation. However, it’s neither binaries nor compiled. It’s called “synthesis”. The OSS license leaves things like that ambiguous and arguable. If it mentions “synthesised” specifically, then there will be less questions on compiled versions of code. So, a OSHL is absolutely necessary if we wish to see better proliferation and uptake of hardware designs.

Then, the whole question on whether we actually need OSH at all, is just silly. Coming from a platform that advocates open source, I cannot imagine such a silly question being asked. They raise a question on whether or not people can hack hardware like they do software. Since not many people can afford to play with hardware (even with FPGA) and fewer still can afford tape-out runs, the article wonders who the license would actually benefit. The answer was given straight by one of the comments, everyone. If hardware was open sourced, there would be very little problem writing OSS drivers for it. There would no longer be a need for reverse engineering to write Linux drivers. The people can just look at the hardware source and write the drivers directly.

We haven’t even gone into the whole idea of community hardware development. Complex pieces of hardware like modern microprocessors have lots of bugs in them. Wouldn’t it be nice if there were many eye-balls looking at the design code to help fix it? I have always thought felt that greater transparency in everything is a good thing for everyone. Let’s stop all these secrets.