As our FPGA must communicated with the gumstix using the GPMC bus, 2 clock must be used on the FPGA : GPMC clock for data transfert and, the internal FPGA clock for all the other operations.
To isolate the two clock, we use a dual clock fifo (a altera’s megafunction). Yesterday, Sylvain and I worked all day long trying to make work the fifo (and correcting some problem of simulation … ) in order to turn on LED indicated by the gumstix. It was not a success so, we will keep on working on this problem today.
We worked on the FPGA this last days.
While I was working on controlling the LED driver, Felix and Sylvain worked on the communication with the gumstix. The news are good :
- the communication between gumstix and FPGA is now working. But, the module for the communication must be modified because, in our real system there will be 2 clock : the FPGA clock and the gumstix clock (just for the data transmission). Felix and Sylvain have finished to implement this new architecture but, it must be tested.
- the control of the LED driver is perfect: we can now turn on all the LED on the propeller, choose the color and the intensity
The next steps are controlling the LED thank to the gumstix and, writing in the external RAM.
The FPGA is now able to do a write access with the GPMC (a read access is not possible for the moment). While Sylvain will work on the reading problem (there are some problems with nOE signal … ), I will test some final modules on the FPGA. All modules are written (with the new calculation flow) and, most of them (but not all for the moment) are tested on simulation. Today, I want to test on the FPGA some modules : ram controller and ram switch modules.
Although I had finished implementing the calculation block in the FPGA, a discussion with Alexis changed the general architecture of this block. The choosing architecture is the following :
This architecture is simpler. I will now begin to implement it.
Afeter correcting some hardware errors, we spend the two previous days working on programming the FPGA. Now, we are able to command the GPIO of the gumstix and, the program JAM STAPL uwhich we use for programming the FPGA is ported on our system. FPGA answer to the gumstix when programming program is started but, for a reason we don’t know for the moment, 0 device are detected on the JTAG chain.
Because of our problem with the GPMC to communicate with the FPGA, we probably will command a new board. So, befoe buying a new board, we want to test if the FPGA programming (which does not use the GPMC but 4 GPIO to communicate with the JTAG ports of the FPGA) is working. So today,I worked on porting the software (jam STAPL )on out system (software which probably did not work on a system before I modify it). Now, the software is compiling and, tomorrow I will try to run it on the gumstix.
I began to debug the general system on the FPGA too but not a lot.
This week-end, I worked on the FPGA. All modules are written excepts the gumstix communication module because we have some problems with the gumstix I will explain next. I wrote a module to debug all system reading in ram (and so a module to simulate the ram behavior): debug is in progress.
On the gumstix, we use the NCS0 as chip select but, even if gumstix allows us to access to this signal, it is yet used by the NAND (which is not explain in the gumstix’s “data sheet”. So, we can’t use the GPMC to communicate with the FPGA for the moment. We have thought about several solutions: hardware patch (if it is possible) but, before doing this, Felix is trying to find a software solution to disable the NAND to be able use the GPMC with the FPGA …
This week I worked on FPGA programming.
I have improve the general architecture :
The calculation block is now more precise : the pre-calculations will not be store in the two external RAM, but, my previous calculation had shown that we can store the pre-calculations on the FPGA RAM. This idea allows the FPGA to access in parallel to the pre-calculations and the pixels store in the external RAM. However, we are just able to store a quarter of pre calculations, the other are calculated thanks to symmetry.
The following blocks are implemented and tested by simulation:
RAM controller, Switch RAM, Fetch pre-calculations, RAM FPGA.
The Fetch pixels block is implemented but not tested yet.
I have begun to implement the gumstix communication block. We have decided to use the following protocol :
We have a 20 bits width address bus between gumstix and FPGA : 18 are used to communicate the address and two to choose the communication mode : 00 : gumstix will write in the external RAM, 01 : gumstix will write in the FPGA RAM, 10 : command mode (to command a RAM switch for example), 11: not use yet.
Now PCB are finished, I work on the FPGA. RAM_controller and RAM_switch blocks are designed and tested. For the good inputs, there are the good outputs in simulation.
Today, I thought about the problem of calculation: even if the calculations can be done before and then stocked in RAM, I thought that it can be faster to do that on the FPGA. It is the case but, the difference is not quite important and, writing a C program to do it is really easier and faster. S, I wrote this program which create a text files containing the result of pre-calculations. This program is working.
I designed the block which will communicate with the gumstix but, I have some doubts on it and, I didn’t test it.
Now, I have to design the other parts of the FPGA and, to adapt the JRunner program (it is the software we will use to program the FPGA thanks to the gumstix) which was design for a windows system.
Yesterday we worked on propeller PCB designing and routing. The problem we had was that our PCB was too expansive (because we need a 4 layers PCB). So, we decided to use 2 PCB: one for LED and the other for the FPGA, the Gumstix, …
I personally worked on the LED PCB which is almost finished …