Friday, January 27, 2006

Everybody Loves Field Programmability


If you have the choice to buy one product at the same cost, one has the upgrade ability while the other does not, most likely you will choose the former one. This is the current trend of the electronics product, which includes the big-market consumer products. More and more electronics product designers intend to put in some effort to provide the field programmability platform for their products.

Nowadays, due to the nature of the highly-competitive business world, time-to-market becomes utmost critical. If you can rollout your products faster than your competitors, your products are likely to be emerged as the product winner because your product gains the market faster than anyone else. Although your product is rolled out with the fundamental features required, the users can upgrade your product with the latest features and firmware later after purchase. This is possible if your product has the field programmability feature and this can be done using a FPGA or even CPLD. Cool huh?

Due to this reason, don’t forget to check if the electronics stuff that you are interested provides any feature upgrade ability. If you already have purchased some electronics stuff with the feature upgrade ability, then don’t miss out the latest version of features for your electronics stuff. The reason is simple; you have already paid for all the future upgradeable cool features from the moment you paid for it. Another reason you should upgrade to the latest features is the current features may have bugs and therefore don’t work well. Anyway, when you find out that the latest features fix the previous version bugs, don’t blame the engineers because the stakes is too high, the schedule is so tight and the time-to-market is getting shorter and shorter!

Actually, the field programmability is not only limited to consumer products. A very good example of the importance of field programmability is for the base station used in cell-phone communication. Base station is the radio transmitter and receiver which transmits and receives all of our calls to or from our cell-phones in a particular area (which is also called cell). We all realize that cell-phone technology upgrades very fast and the base stations just have to catch up with the latest technology used. Imagine what would happen if the base stations don't have the field programmability? I believe it would cost the telecommunication companies a lot just to keep their base stations updated with the latest features in the cell-phone technology! Just think about the base stations located high on the mountains you will know what I mean.

If you are still not sure with what I am trying to bring out here, there is a good and simple reference design for you to read, of course, provided that if you are interested to know more. This reference design targets the Altera Stratix FPGA which has the remote update configuration feature.

That’s why everybody loves field programmability!

Thursday, January 26, 2006

Soft Processor in FPGA


If you are new to FPGA, your might wonder what is the advantage of using a soft embedded processor in a FPGA. Examples of the famous soft processor in the FPGA are Altera NIOS II and Xilinx MicroBlaze. Why not using a dedicated microprocessor such as Microchip PIC microcontrollers, Motorola 68000, ColdFire or others? There are quite a number of reasons for this. Below are some that I can quickly think of.

First, you can configure as many I/Os as you desire in a FPGA as long as the FPGA chosen by you can provide that. For an example, most of the dedicated microcontrollers have the most 40 I/Os, but with a FPGA, you can have as many as 300 I/Os or even more if you are willing to pay more, and all of the I/Os can be controlled through the soft-core processor programmed in the FPGA.

Second, you can design your very own customized Intellectual Property (IP) inside the FPGA to interface with your processor. Of course, your IP would reside inside the same FPGA, too. The IP can be written in Verilog, VHDL or vendor-specific hardware description language such Altera AHDL or Xilinx XDL. For an example, in my previous post, I mentioned that I had done USB device IP cores inside FPGA. In fact, these IP cores interface with the soft-core processor inside the FPGA. The reason for having a separate IP core for some dedicated function is to have a higher performance, such as USB High Speed transfer (480Mbps) with PC. A dedicated controller alone might not act as fast as an IP core in a FPGA. For that reason, I never see any dedicated controller that supports USB High Speed transfer, at least not as far as I know. Most of the dedicated controllers only support USB transfer up to 12Mbps, which is actually the USB Full Speed transfer.

By now, you may ask, why not creating the whole design in a FPGA without the soft-core processor? Actually you can. But there are cases that you want the simplicity of writing part of your design using C/C++ code, especially those design portions that require massive processing power. See my previous post . Most of the time, using a processor helps reducing your design time and save your FPGA cost, because less logic is required if you design is relatively complicated.

Third advantage of using a soft processor in a FPGA is, you can increase your operating frequency as high as the timing requirement in your design is met. For most of the dedicated controller, you have to follow the frequency specification.

Well, enough has been said for the goods of the FPGA. Is there anything good about the dedicated microcontroller? Cost, of course! Every penny counts, you have to pay for the cool features of a FPGA!

Wednesday, January 25, 2006

C or HDL in FPGA?


There are always two options to create one design in FPGA, first through HDL and second through C language. Many FPGA beginners always ask me whether they should design their IPs in HDL or C in the FPGA. HDL, a.k.a Hardware Description Language, refers to the well-known verilog HDL or VHDL language whereas C in this article refers to the common C or C++ programming language.

If your IP needs very fast performance, it is best to design it with HDL because the design is in RTL (Register Transfer Level) and you know exactly how many clock cycles taken to transfer data among all the registers. You also define and create all the state machines needed in your IP. Using HDL, you can create as many parallel processing as possible to improve your design performance. The downside when designing with the HDL is it always takes more development and debugging time than designing with the C. Sometimes, simulation is required to make sure the HDL design behaves as expected at the targeted operating frequency.

You probably learn C language earlier than HDL in your life. So, needless to say, you most probably feel more comfortable when creating your IP in C. Besides, it always takes less development time and much easier to debug as most C compiler provides a user-friendly debugging platform. The disadvantage for C is that you can’t control much about the timing performance. You usually don’t know or you don’t even bother how much time taken to execute one function in your design. The most critical downside of C language is that you can’t do parallel processing. Everything works in serial with C, except when the DMA (Direct Memory Access) is called to work. The most you can do with C is code optimization and use the DMA as frequent as possible.

Although there are pros and cons for both design entry with HDL and C, you can actually combine both in your IP to optimize your IP performance as well as to shorten the time taken for your IP to market. For the design portion that needs critical performance, design it with HDL. On the other hand, for the design portion that requires many processing, design it with C to save some development time and also your limited logic resource in the FPGA.

In the digital world, many people refer the engineers who do their designs using HDL as Hardware Engineer whereas the engineers who write C code as Software Engineer. Many hardware-software integration issues appear due to the clear line drawn between the Hardware Engineer and Software Engineer. Due to this reason, I hate to call myself as either one of them because for me, both are just equally important.

There is a very good article that talks about the issues raised when integrating hardware and software. Feel free to read the interesting “When Hardware Met Software” from Xilinx. This is the reason I love Xilinx, they keep on publishing interesting and useful articles for public for FREE!

Tuesday, January 24, 2006

Communication Link between FPGA and PC


Nowadays, PC has become the most common platform for everybody. You use PC to store your personal data, business statistics, financial documents, digital photos, songs, etc. You also use PC to communicate daily with your family and friends through emails and messengers. For that reason, I think it is fair to say that the communication link on an embedded system with PC becomes more critical now than ever. One common example, almost all of the every recent generation of cell-phones can be connected to PC through USB.

If you have a FPGA on an embedded system, you find that at times you want your embedded system to talk to the PC. Luckily, a lot of Intellectual Properties (IP) have been designed by great FPGA companies such as Xilinx and Altera to build the connection between the FPGA and PC. Therefore, if you want to save yourself hassle from designing your own IPs, you can just buy those needed IPs from the targeted FPGA companies. Of course, these IPs are not for free but big companies certainly afford to buy the licenses for these IPs.

I personally have the experience to design and implement the communication links between a FPGA and a PC. I have designed the IP (using verilog) in the FPGA to talk to the PC via Parallel Port, Serial Port and most recently, the popular USB port. It is an wonderful feeling when I successfully communicate with the PC USB port from low-speed (1.5Mbps) to full-speed (12Mbps) using only a Cyclone FPGA and later HIGH-SPEED (480Mbps) using a Cyclone FPGA with the help of a NET2272 chip! The most difficult part when getting started is to enumerate the USB successfully. If you are already able to create an IP that can enumerate the USB device successfully with a FPGA, you are almost half way through. It is not easy but it is certainly not as difficult as you may imagine.

Monday, January 23, 2006

Hello World!

Hello World from fpga forum!

Please bookmark this forum as more interesting posts will be published for you soon!