FPGA-Project

Latest News

2011-05-23	Foundation of Creonic
After finishing my PhD last year, I started a spin-off together with a colleague of mine. The spin-off is named "Creonic" and we are selling IP cores and developing communication systems for ASIC and FPGA. One of our main focuses is forward error correction, in particular LDPC decoders and turbo decoders. Further technologies in our portfolio are BCH codes, RS codes, convolutional codes (Viterbi decoding). But we have deep knowledge in other areas as well (such as synchronization or MIMO). Our products are available for a wide range of applications, such as UWB low-power systems, satellite communication systems, DVB-S2/DVB-T2/DVB-C2, or high-throughputs beyond 1 Gbit/s. Furthermore, we are offering VHDL and embedded systems design services. Just visit our websites to get more information: Creonic www.ldpc-decoder.com
2010-01-04	DSP Development for Atari Coldfire Project
Within the last half year I was writing my PhD thesis, so I didn't do much with FPGAs during this time. A bit more than one year ago, the Atari ColdFire Project (ACP) was revitalized. The goal of this project is to build an Atari Falcon compatible computer based on the Freescale ColdFire CPU. In the meantime the prototypes have arrived and the software is starting to run. The good thing about the ACP computer is that an FPGA is on-board in order to emulate the custom Atari chips or chips that are no longer commercially available. Most chips are already available as VHDL source code from the Suska platform, which is an Atari ST rebuilt in an FPGA. About one year ago I started the development of the Motorola 56001 DSP in VHDL. It was part of the Atari Falcon computer and used for realtime audio stuff, but also 3D rendering in several demos. Within three months I was able to get a working processor pipeline with instructions for branches, loops, and arithmetics. The DSP runs at about 30 MHz on a Spartan3 FPGA, which is less than the 32 MHz as in the Falcon. But in contrast to the original DSP, the pipeline is able to perform most instructions in one clock cycle instead of two clock cycles. So I hope that the DSP will be faster than the original at the end of the day. The problem with the clock is the complex ALU, which supports 24x24-bit multiplications and has a postponed 56-bit accumulator for MAC instructions. The FPGA is just not suitable for such high word widths. However, I didn't do much on this code for the last nine months. Things like external memory access, interrupts, and other interfaces are still missing. I will try to spend some time on it in the near future. Atari Coldfire Project FPGA-based Atari ST (Suska)
2008-10-15	Tackling the ML507
After my research group had bought an ML507 evaluation platform I spent some time with it. I created a rapid prototyping platform for the reconfigurable application-specific instruction-set processors (ASIPs) that are developed within my research group. I use Genode FX to control the platform, a screen shot is to be found in the picture section. This board was demonstrated at the FPL'08 in Heidelberg last month. Even Ivo Bolsens, the Xilinx CTO, visited our booth (see picture section)! I also ported the realtime fractal to the ML507. Since the Virtex5 on the board has much more DSP slices and thus multipliers it was possible to increase the number of iterations per pixel. Thus, the fractal looks much more detailed than on the Spartan3A starter kit board. I now use 128 iterations per pixel, the resolution remains unchanged at 640x480, and only half of the multipliers are used. Zooming further into the fractal is only prevented by the precision of the multipliers (see picture section). Visit the picture section
2008-09-07	Genode FX on Virtex 5 PowerPC
Yesterday, I made a new release of Genode FX. This new release supports for the first time the PowerPC 440 as used in Virtex 5 devices. A demo for the Xilinx ML507 board is also included in the release. In this demo, the PowerPC is clocked at 300 MHz. The DVI connector is used as video output, whereas the resolution is 1024x768. Learn more about Genode FX Download Genode FX
2008-08-27	DOpE on Spartan-3A Starter Kit: Released as Genode FPGA graphics (FX)
Today, all components required to run DOpE on the Spartan-3A Starter Kit were released as open source. Genode FX contains my PLB cores (NPI VGA/DVI and PS/2 controller) as well Norman Feske's DOpE version adapted to these cores. It is thus possible to create custom user interfaces as well as adapting the system to custom FPGA boards. In the near future a demo version for the ML507 development board is planned. This version will use the PPC440 available in Virtex5 FPGAs. Learn more about Genode FX Download Genode FX
2008-02-15	DOpE on Spartan-3A Starter Kit: YouTube Video
I just uploaded a small video to demonstrate DOpE on the Microblaze. Unfortunately the quality is rather poor. YouTube Video
2008-01-22	Playing around with Spartan-3A Starter Kit
The other day I had some time to play around with my FPGA boards. I started working with the Spartan3A Starter Kit Board that was given to me by Xilinx in exchange for the real time fractal they ship with the board. What I was missing was a simple frame buffer that allows for drawing a screen by the Microblaze. The Euterpe Board has synchronous SRAM as memory, so it wasn't that hard to write an own memory controller with an integrated VGA controller. The S3A-Starter Kit uses DDR2-SDRAM instead. Since I didn't want to write a controller for these memories I decided to use the MPMC3 (MultiPort Memory Controller) from Xilinx instead. It supports the S3A board and can be connected to various other components in the system. I created a VGA controller that connects to this memory controller via the NPI interface. In case new pixel data has to be fetched, the VGA controller sends burst requests to the memory controller. The memory controller sends these requests to the DDR2-SDRAM. Other components connected to the MPMC3 are the PLB bus and the XCL cache connections. To guarantee a correct working of the VGA controller it has the highest priority. The VGA controller has besides the NPI interface also a PLB interface to be able to set certain things like start address of the frame buffer or the resolution (supported are : 640480, 640240, 320480, and 320240, each at 16 bits). A first testing program (a cube made of lines that rotates - written by Norman) showed me, where the bottleneck of this system is, when using it for graphics: Clearing a screen of 640*480 with a 16 bit color depth takes as much time as displaying 1,5 pictures at 60 Hz! So when trying to do some demo effects already clearing the screen will allow for a maximum of 40 fps!! I measured these things as I did back in the Atari times. The VGA controller supports to set the background color of the screen. When I start clearing I set this color to blue and when I'm finished I set it to red for instance. I had a look at the assembler source code of the clearing routine and saw that clearing two pixels takes five assembler instructions. By rewriting the loop in the C code it could be reduced to four instructions, but still this was much too slow (1,2 pictures for clearing). Therefore I decided to include a hardware clearing in the VGA controller. Two additional registers in the VGA controller are necessary for this. One gives the start address of the area that has to be cleared, the other one gives the amount of pixels that have to be cleared. When writing to the latter one the clearing is initiated. An interrupt is generated when clearing is finished. Like this clearing the screen could be reduced to about 0,3 pictures! Now plenty of computation time is left for some demo effects, but I guess drawing them is still quite slow. That is the reason why I introduced the low resolutions. When the VGA controller was running decently I decided to port Norman's DOpE to the board. All one needs for this is a frame buffer and a mouse controller. A PS/2 controller I did for the Euterpe board already. Since it was used with the OPB bus and this bus seems to be obsolete now I changed its interface to the new PLBv46. Adapting it was quite easy and it worked immediately with the S3A-Board and my new design. When porting DOpE I had some minor issues. For instance I realized that the frame buffer address has to be aligned to 64 byte addresses, since the VGA controller performs burst requests. But these issues are solved now and DOpE is running fine. I have the impression that it outperforms the port to the Euterpe board, even though it is running from DDR2-SDRAM now instead of the fast ZBT-SRAM of my Euterpe board. Furthermore the clock frequency is only 50MHz at the moment, compared to 61,44MHz on the Euterpe board. Since the system seems to work fine I'm going to boost the clock frequency to 66 MHz. Currently I'm thinking about coding some demo effects for this system. The Starter Kit should be somewhat popular, so other people will be able to give these things a try. Norman's site.
2007-04-14	Coding week with Norman
One month ago (sorry, I was too lazy to update the site) I had a wonderful coding session with Norman. I used the time to play around with CoWare's LisaTek (aka Processor Designer). In only one week I had a working RISC-like CPU with four pipeline stages running on my Euterpe board. At first I tried to implement some instructions that could be useful for 3D processing. But then I realized that implementing instructions without developing an application at the same time is not that effective. Thus I changed my strategy and dropped the 3D instructions (for instance I wanted to use three different memories: one for each coordinate (x,y,z)). I decided to build the processor with such a functionality that a simple star field-demo could be displayed on a VGA monitor. As a result I was much more target-oriented when describing the processor in the LISA language. You have to know that I only started to learn the LISA language. When I first did some synthesis I realized that the processor was huge! It consisted of 32 GPRs each with 32 bits. I thus reduced this set to 8 GPRs each with 16 Bits only. Still the design was quite large, even with only a little functionality. I realized that it is quite important for the VHDL generation how one writes the LISA code and therefore kept in mind some coding guidelines. The functionality of the processor quickly grew and it suddenly supported: indirect addressing (with postde-/increment of the address) all basic ALU operations (add, sub, mul, shifts, logical conjunctions) absolute jumps hardware loops (zero overhead loops) conditional branches load/store operations that even stall the pipeline when necessary Always when there was an operation for the star field that the processor didn't support I simply extended the LISA description of the processor. Thanks to the Processor Designer one only needs a simple Makefile and gets assembler, disassembler, linker and simulator that fit the description of the architecture. Basically the processor is not that special. One nice feature is that it supports fractional multiplications, which is very useful for complex multiplications (that is needed for the rotation of the stars). For the projection of the stars one needs a division. Since dividing in hardware is not that simple it is realized with a look-up-table of 1/x and a fractional multiplication. I didn't implement special instructions for the 3D stuff. In a first version the star field ran with 2,750 FPS, so even a slow down loop was necessary. Norman debugged his SRAM controller and designed it with two ports. One port can be used for the VGA controller to realize the frame buffer functionality, the second one can be used for any other purpose. To display the picture on screen I used his SRAM-VGA-Controller for the processor. You can find a screen shot in the picture section. Norman also developed a RISC processor, but he did it the hardcore way and coded it in VHDL. For details see his site. Furthermore he triggered me to get the camera module I never used with the board out of the cellar. First it was necessary to solder some wires to make sure that the digital I/Os are working with 3.3V instead of 5V as set by default. In only a few hours Norman could display a picture on screen and even manipulate the colors of the picture with volume of the line-in port (with my PCM3010 controller). Here are some pictures. Here is the source code of the star field. Here is a small log of the coding session (German only). Norman's site.
2007-01-30	Fractal on Spartan-3A Starter Kit
I just wanted to mention that the fractal is shipped in a slightly modified version with the brand-new Spartan-3A Starter Kit as a part of a demo configuration. Eric Crabill from Xilinx asked for permission to use the code and did the modifications. The fractal is now controlled with the buttons on the board instead of a PS/2 mouse as it is in the original design. The board costs $199. Spartan-3A Starter Kit Board Spartan-3A Starter Kit Demo Design
2007-01-06	Genealogy site opened
Since I'm working at the University I don't find much time for working with my FPGA board. Hence nothing happened with it in the last months. However I am still doing a lot of VHDL coding. For instance I developed a powerful VHDL model for a duo-binary Turbo Code decoder that uses 8 or 16 states for the Trellis. At the moment I'm on holiday. The other day I booted my Atari Falcon and transfered my genealogical database to the PC. With GRAMPS under Linux one has much more possibilities than on the Atari. And so I created a web site of my family tree, that consists of about 400 persons. Look here.
2006-04-13	Diploma thesis finished
Finally I did it! The 31st March I delivered my diploma thesis, the 11th April I had my final presentation. So now I am a Diplom-Ingenieur :-). My diploma thesis has the title "Synthesisable IP Cores for Irregular LDPC Code Decoding Based on Highly Flexible Architecture Templates". There I developed two highly flexible LDPC code decoder in generic VHDL code. With this generic VHDL code, different supported scheduling strategies and three suboptimal algorithms one has a powerful construction kit to compose the LDPC decoder of choice in terms of throughput, area, communications performance and codeword size. The templates could be used for standards like DVB-S2, IEEE 802.16e (WiMax) and IEEE 802.11n (WiFi) that contain LDPC codes for the forward error correction (FEC). Also I developed an IRA LDPC code encoder, that allows encoding like necessary for the DVB-S2 standard. You can download the diploma thesis in the Files section. The 31st March I also organized a party together with some friends. Photos are located here. I will start working at the Microelectronic Systems Design Research Group at the University of Kaiserslautern the 1st May.
2006-02-04	Coding week in Dresden
Last week I stayed for some days at Norman's flat in Dresden (just before the birth of his son sometime in the near future). Together we held a VHDL coding session with the two Euterpe boards. Norman did his first steps in VHDL coding and learned quite fast. He almost did a whole FPGA/VHDL course of my university in just two days (the course is meant for one semester). After that lab he felt good enough to write his own ZBT-SRAM controller. When I left Dresden this controller was still buggy but I have no doubts that he will make it working.. I used these days for several things: First I tried to debug the controller for the PCM3010-CODEC. I think it sounds better now, but I might be wrong.. I should measure the properties again to be sure. After fiddling around with the CODEC I decided to port PacMan to my FPGA board. There exists an emulation of the arcade machine from 1980 by MikeJ (see www.fpgaarcade.com). The problem of this implementation is that it seems to need external memory. Eric Crabill of www.fpga-games.com adapted this implementation to his custom FPGA board that is using a Spartan3-400 (just as my board). With his changes it is not necessary to use external memory anymore. ROMs and RAMs are now realized with the dual ported BRAMs of the FPGA. I used Eric's work and ported the design to my board. I removed the controller for the N64 controller and the Delta-Sigma-Converter. Instead I now use a PS/2 keyboard for controlling and my CODEC for sound. Altogether it wasn't that much work, thanks to MikeJ and Eric Crabill! After I finished PacMan and played quite a bit with it I considered to port Asteroids, too. But the motivation wasn't that high to port another game. Though I think I will port it sometime. Instead I gained experience with the DCMs (Digital Clock Manager) in the Spartan FPGA. These are used to manipulate clocks in terms of frequency and phase. I wrote a model that displayed a test pattern that was written to and read from the SRAM. The clock for this frame buffer was generated by a DCM. I used up to 147MHz to clock the SRAM with. The design seemed still to work. But it's not for sure since I didn't use a RAM tester and just saw a test pattern on a VGA monitor. As a special feature I made the phase of the SRAM clock variable. I can control the phase with a PS/2 keyboard and hence it should be possible to find the highest possible frequency for the SRAM. As I said I need to use an SRAM tester. Anyway it's nice to see how the frame buffer is failing when the phase is out of a certain range.
2005-12-10	Still alive
Phew... It has been a long time since the last update. First of all you will recognize that I made a major rework of this site. It's still not very nice, but for sure it's better than before.. Indeed I didn't do very much with the FPGA board in the last 6 or 7 months. In May I tried to build an audio amplifier but the design wasn't correct and so the amplifier refused to work. You will find a picture in the picture section. Last week I tried to build a new one but I'm not satisfied with the result. The design is correct now but the op-amp I use seems not to allow a very high amplification. During summer I wrote a thesis with the title "A flexible IRA LDPCC Decoder Architecture for FPGAs". The core I wrote for this thesis will be used in the 4MORE project of the European Union. After writing this thesis I spent three weeks in La Rochelle, France. There I visited a language school and tried to learn French a bit. Malheureusment mon français est très mauvais encore. Mais maintenant je peux parler un petit peu. Also during summer I fitted the second PCB with components. This board seems to be OK, too. I tested DOpE on it and encountered no problems at all. It is now in the hands of Norman for he wants to gain experience in VHDL coding. I'm really anxious to see his first steps! One month ago I started working for my diploma thesis. The title isn't fix yet but it will deal with LDPC decoder architectures again. I will enhance the architecture of the previous thesis, implement encoder architectures and a decoder core that will be capable of decoding some of the upcoming Wimax codes. Two weeks ago I visited the Atari-related coding convention Paracon7. Meeting all the guys of the Atari scene again was really nice! But instead of bringing my Atari Falcon030 with me I decided to build up my FPGA board. With Norman I fixed some bugs in DOpE. It now runs more stable and faster. I also had the motivation to do something new with the FPGA. I did a Mandelbrot-like fractal in VHDL that uses all 16 hardware multipliers in the Spartan3. For this 8 concurrently working pixel calculating units are used, each containing two multipliers. This architecture allows me to calculate every pixel of the 640*480 fractal in real time (60fps!) with the electron ray of the monitor, 16 iterations per pixel are supported. Last week I added mouse support to the fractal. It is hence possible to select an area of the fractal and zoom in or out using the left and right mouse button. When one uses the third mouse button a demo mode is enabled that zooms in and out extremely fast. This mode impressively demonstrates the real time calculation of the fractal. The VHDL code for the fractal is available, see the files section.
2005-04-18	Measuring of CODEC properties
The advantage of studying at a very small university (Kaiserslautern counts appr. 8000 students) is that you know most teaching people and that you can torture them with questions and such things all the time. Last week I was at the group for Digital Signal Processing and asked whether it was possible to measure the Frequency Response of my board. You can see the results here: Frequency Response, FFT of a 1kHz signal. All measurements were made at a sampling frequency of 48kHz, the data from the ADC is sent back to the DAC immediately. The Frequency Response looks quite normal. But when using a 1kHz sine signal you can see heavy distortions at 3, 5, 7, ... kHz. Currently nobody knows where they come from. Maybe it is because of a poor board layout or maybe I'm doing something wrong when reading from the ADC and writing back to the DAC. A measurement of THD+N (Total Harmonic Distortion + Noise) resulted in only -50dB. According to the data sheet about -96dB should be possible.
2005-04-03	Development snapshot
I just took two pictures of Euterpe in action: Dope, System. The first one shows DOpE that is running on the MicroBlaze-processor in the FPGA. The first window can be used to toggle the state of the LED, the second window is used to set parameters for the pong game that is running on the second VGA monitor. At the moment only very few parameters are supported. The second picture shows the whole running system: DOpE on the left monitor, Pong on the right one. As mentioned earlier the beaters are sound controlled. The next idea I have is to use a timer in the MicroBlaze design. Also it would be nice to store the parameters made in DOpE in the second serial Flash so that they are not lost when turning off the power. And finally DOpE should start up automatically when powering the board. This can be done by using the unused part of the configuration Flash (about 300KB) for program storage. Currently I'm uploading the DOpE-binary with a debugging-tool.
2005-03-28	Schematics online
The schematics of Euterpe seem to be fine so I decided to put them online. Grab it here. If you have any questions about it don't hesitate to ask. Around easter I implemented a small Pong-game in Hardware. To move the beaters you have to shout into a microphone what is a lot of fun!! When Pong was running fine I made an OPB component out of it and connected it to the MicroBlaze-Processor. Now both VGA connectors are used, the first one for DOpE and the second one for Pong. So it is possible to watch DOpE on a monitor and Pong on a video beamer. DOpE can be used to change the parameters of the game comfortably even when playing. I will make a photo of the running system in the next days.
2005-03-22	SRAM-VGA-Controller is working
Finally I did it (YES!). The SRAM-Controller and the VGA-Controller are merged now in a single core. To make the SRAM work in every clock cycle I am now using a phase shifted clock (180°, so it's just the inverted system clock). Besides this I had to reduce the frequency of the whole system from 86,016 MHz to 61,44 MHZ (1,25 * 49,152 MHz). Although every core I designed is running with more than 100 MHz it is impossible for the router to achieve these frequencies when all components come together. At the moment 1456 of the 3584 slices in my FPGA are used. Here is a picture of the current FPGA layout made with the Xilinx FPGA editor. With the lower system clock I also had to change the pixel clock. It is now 30,72 MHz instead of 21,504 MHz which allows a screen of about 800480 at 60Hz. Anyway I display every pixel twice which results in a resolution of 400480. The VGA-Controller would have to request video data every 4th clock cycle in the first case, with the current resolution it still needs to request data only every 8th clock cycle. DOpE is running now at a very useful speed :-) Anyway there seems to be an issue with the interrupts. When I remove a debug output to the serial interface in the interrupt routine DOpE doesn't recognize that the mouse button was released. With this debug output the system freezes for very short moments when the sending buffer of the serial interface is full, but releasing the mouse button is recognized. This is a software problem I guess.
2005-03-20	CODECs are working
Today I managed to receive audio data from the ADCs and send it back to the DAC. To make it work wasn't very difficult - the core VHDL code consists of just 72 lines. The ADCs need line levels so an amplifier is needed when one wants to connect a simple microphone. At the moment only the digital video camera and the second serial Flash aren't tested. Besides this I dug deeper in the SRAM problem. It seems that I have timing problems inside the FPGA. Therefore it might be necessary to reduce the clock frequency. I also tried to use a by 180° phase shifted clock for the SRAM. A smaller design I did then works, but the bigger one I use to run DOpE still fails. The EDK seems not to use very good synthesis options and I have no clue how to change these options in the EDK.
2005-03-09	Problems with SRAM
The last days I spent many many hours with including the VGA-Controller into the SRAM-Controller. But I just couldn't make it work properly. When I don't initialize the frame buffer writing to the SRAM works. But when I try to write to the SRAM when the VGA-Controller is working things go totally wrong. Writing to the SRAM seems to work during the vertical or horizontal blank. But when I try to write while the VGA-Controller tries to fetch video data from the RAM it seems that the writings are done at the addresses where the VGA-Controller just tries to fetch the data. The architecture of the SRAM and the SRAM-Controller should make it possible to read or write every clock cycle. But obviously it's not. Maybe I have some problems with clock skew.. I'm not sure about that and have no idea what to do.
2005-02-20	Almost no progress
Currently I almost have no time to work on the board. I will have some exams in the next weeks and I'm also busy with my job at the university. There I help to develop an FPGA-based LDPC-decoder. Doing VHDL designing in the morning and in the evening is just too much.. However I implemented an own SRAM-Controller and connected it to the OPB. It uses a fully pipelined architecture so that I can feed its pipeline with new memory requests every clock cycle. The next step is to implement the VGA-Controller in the SRAM-Controller. With the current pixel clock (21,504MHz) the VGA-Controller only needs data from the memory every 8th clock cycle(32 Bit bus, 16 Bit video mode). I also coded a very small DOpE application. In it I have two buttons that are used to toggle the state of the LED on the board ;-) Money counter addition: - 5,00 EUR PS/2 mouse
2005-02-09	Problem "solved"
Yesterday I was at the university and had the possibility to use an oscilloscope. Kolja had the idea that there might be noise on the TCK-line of the JTAG interface and therefore the FPGA thinks it has to do something (like reprogramming itself...). First I tried to reduce the noise with a pull-up resistor but this didn't work. With the oscilloscope I could see that there was no heavy noise, but I saw when running the XMD tool of Xilinx it is communicating with the FPGA all the time. XMD is used to upload the binary of the MicroBlaze into the SRAM. So I simply quit XMD after uploading and starting the program and the problem disappears! I guess there is a bug in this software. Also the initialization of a PS/2 mouse works now and so I can finally interact with DOpE. The speed of DOpE isn`t very impressive at the moment, but I think there are some things that can be optimized. For instance including the SRAM- and the VGA-Controller in a single core should result in an enormous speed up and a much smaller design.
2005-02-07	Hardware-/Software-Codesign Coding Weekend
Last weekend Norman Feske, the author of the GUI "DOpE", visited me at my student's flat. Together we tried to port DOpE to my FPGA-board using the MicroBlaze processor and the Embedded Development Kit (EDK) of Xilinx. I designed a very minimalist VGA-Controller and connected it to the OPB (On-chip Peripheral Bus) allowing the programs running on the MicroBlaze to use a frame buffer. The controller gets its video-data by burst accesses to the SRAM using a 16 bit resolution and a 21,504MHz pixel clock resulting in a resolution of 576*480 at 60 Hz. Unfortunately the SRAM-memory controller by Xilinx doesn't support synchronous SRAMs very well (one read or write cycle takes about 8 clock cycles!), so the system is not able to deliver the needed video-data fast enough and the displayed picture contains errors. Therefore I started to implement my own SRAM controller, that will make use of pipelined SRAM access. Beside the VGA-Controller I implemented a PS/2-Controller and connected it to the OPB as well. This controller has to read events from mouse and keyboard, giving the MicroBlaze an interrupt when something happens. Currently the mouse-part isn't working for the initialization of a PS/2-mouse is harder than I expected. Norman made some changes to DOpE, so that it finally booted, initialized the frame buffer and was able to get the input of the keyboard. BUT after a few seconds watching DOpE on a VGA-monitor the whole system seems to collapse. I don't know what this could be, since even the FPGA seems to be affected (for instance the DONE-pin suddenly has a voltage somewhere between high and low). When the MicroBlaze-Code is stored in the FPGA instead of the SRAM everything works fine, so maybe there is a kind of bus collision between MicroBlaze and the VGA-Controller. Still a lot of work is left..
2005-01-27	SRAM is working
Just a short note, that the SRAM is working perfectly now. In the UCF-File there was a line that seemed to cause trouble. I set the port for the SRAM clock with "NET SRAM_CLK fast" to give it a fast slew rate. Without this line I have no problems anymore and the SRAM works very well even at 86,016MHz (49,152MHz * 1,75). This is the highest frequency I can use with the MicroBlaze processor. With the download cable connected and a MicroBlaze processor in the FPGA(which means a quarter of the FPGA is used) running an endless memory testing routine at 86,016MHz results in a power consumption of about 180mA at 5V.
2005-01-26	Testing of board progresses
So far the PS/2-ports, the VGA-ports and the RS232-interface have been verified. The last days I spent with the SRAM. I want to use it as program memory for the MicroBlaze processor. It seems to work now more or less, but some memory tests running on the MicroBlaze-processor are still failing. I must verify the connections between the SRAM and the FPGA again. I doubt it is a timing problem - I tested it with 49.152MHz and 12.288MHz and in both cases some tests passed and some tests failed. Money counter additions: - 261,00 EUR Two PCBs - 88,16 EUR Two FPGAs (XC3S400) - 13,92 EUR Two configuration Flashs (XCF04S) - 12,81 EUR Several SMD parts
2005-01-21	Soldering of first board finished
Just have a look. The problems with powering the board mentioned below might be because of the used PSU. When I connect the PSU to the power outlet after connecting it to the board everything works fine. Only when connecting the already powered PSU to the board the problems appear. The next step is to test the components and interfaces on the board.
2005-01-20	FPGA configuration successful
Today I made the FPGA configure via the download cable and the Flash. In the beginning I had some problems with the JTAG chain and realized that I mounted the configuration flash the wrong way(dooh!). After fixing that configuring the FPGA worked as expected. However I have some problems with the power supply. Sometimes the 3.3V and the 2.5V seem to collapse and sometimes the FPGA gets extremely hot. Both problems only appear when connecting the board to the power supply and not during normal operation. Maybe this is a FPGA problem with the ramp time at power up. According to the data sheet turning on the I/O voltages has to take 2ms, what is quite a lot. Tomorrow I want to mount the remaining parts (so far only power supply and configuration stuff are mounted beside the FPGA and the SRAM). Soldering SMD parts is easier than I expected it to be.
2005-01-18	Boards arrived
Today the two boards I ordered arrived. Here are two photos: Top-view; Bottom-view. I immediately started with soldering (well my first steps in SMD soldering) and until now the FPGA and the SRAM of one board are soldered. With kind permission I can use a SMD laboratory at the university and some employees showed me how to solder. I call the board "Euterpe" like the muse. She is the "Giver of pleasure" and the muse of music. More pictures will follow soon..
2005-01-12	VHDL test models
In the meantime I started to write some VHDL models to test the hardware. From a FPGA-lab I did earlier this semester I have some models for reading scancodes of a PS/2 keyboard, displaying a picture with a VGA-monitor and sending characters via RS232 interface. But the very first model I want to implement looks like this: config_test.vhd config_test.ucf . It is just intended to make sure the configuration of the FPGA works as expected. The model simply XORs the two buttons and sends the result to the LED. The UCF-File (User Constraints File) tells the synthesis software which I/Os of the FPGA are connected to the buttons and the LED. Money counter additions: - 26,10 EUR (Hopefully) High quality PSU(5V, 2.5A): www.reichelt.de - 78,10 EUR Digital video camera module: www.sander-electronic.de
2005-01-02	Money counter introduced
I just want to document the costs of this project. Maybe someone is interested. So far I spent 368,92 EUR (including taxes and shipping): - 130,11 EUR Eagle Software(Non-profit version): www.cadsoft.de - 155,87 EUR Several ICs(US-Import): www.digikey.com - 35,32 EUR FPGA configuration cable: www.trenz-electronic.de - 47,62 EUR Several parts (connectors, LEDs, soldering stuff...): www.reichelt.de Note that I bought all parts at least twice since I want to build at least two boards. The boards are expected to arrive middle of January.
2004-12-20	Routing finished
The routing of the board was finished yesterday. In the end I did some slight changes: - Added a second connector with a better pin layout. - Rerouted the switching regulator(which converts 5V to 1.2V) like suggested in the data sheet. - Added some cooling areas for the LDO regulators(which convert 5V to 3.3V and 2.5V). - Changed the JTAG chain from 3.3V to 2.5V levels. Thus I save some resistors. - Configuration mode (JTAG or Flash) is now detected automatically. When the download cable is connected JTAG is chosen. - Added some capacitors between layer 2 and 3 where HF signals jump from top to bottom layer or vice versa to enhance signal quality. - Rerouted the longest wires to the SRAM. Now the routing looks more symmetrical. - Added two 1.2V power supply areas. These act as low inductive capacitors. Now the board can be produced. I asked a company for an offer. They told me two boards will cost 300 EUR. Kolja asked the same company for an offer but he was told two boards will cost only 216 EUR which is a bit weird... So Kolja will order the boards for me.
2004-12-16	New development snapshot
The routing of the board is almost finished as you can see here. I will add another expansion connector with a different pin layout to the board and optimize the routing of the SRAM a bit. The pin layout of this first connector is very crappy and only used because of the camera module. I'm going to finish the board layout this weekend and verify the design again. So hopefully the board can go into production before Christmas. Unfortunately I wasted a lot of area, so the PCBs won`t be very cheap...
2004-12-10	Slight modification of the expansion connector
The video chip of the camera module I want to use supports 5V and 3.3V for the digital I/O. Unfortunately the module seems to connect the pin for the I/O-power supply to 5V in any case and since Spartan 3 isn't 5V tolerant this won't work. So instead of using a flatband cable with 32 wires I`m going to use one with 34 wires. One additional wire is used for 3.3V and one for GND what might enhance the signal quality in the flatband cable a bit. Making the 3.3V available to the camera chip will need a slight modification of the camera module though.
2004-12-07	Site opened
So, let's see the progress of the project: Here is a snapshot of the actual board layout. Of course it's not finished yet. The left part of the PCB is still unrouted and very messy. On the right the SRAM, the DACs for the VGA-ports and the RS232 part are routed so far. I'm not really satisfied with the routing of the SRAM, the long wires can be optimized by routing them under the FPGA and the SRAM instead of around them.