The I2C core made a lot of progress this week. While I was hoping last week not to use a FSM in my slave I couldn’t resist the temptation. My slave have a FSM and is almost 95% ready. The hardest part is the acknowledge part. Not only that the slave need to send acknowledge when the master is writing to it but has to receive acknowledge when it’s writing to the master. Each acknowledge signal has it’s own meaning.
As for the master it is now able to send acknowledge signals and receive them and act based on their value. The only thing left for my master is the features necessary to handle the presence of other masters on the bus such as arbitration and clock synchronization.
The I2C device designed by microchip for its PIC has been my guiding light through the mazes of design decisions. Hence, I would like to hold a comparison between my I2C design and microchips. The major difference is that my designs give less control over the device to the user through software. While this limits the users freedom it makes the I2C core very simple for users which is an advantage in our project that targets hobbyists, for now. I could claim that users running codes for my design don’t need to deeply understand I2C to use my core. Microchip’s design uses many flags triggered by the user to control various behavior of the I2C. Interrupts are widely used to signal the end of the current stage to the user after which the core waits for the right flags to be set by the user to continue its activity.
On the other hand my device uses no flags at all. My I2C is simply triggered by the user wishbone writes to the data and address registers. The status flags that the user can read only indicate general states such as busy, free, empty buffer, full buffer and error. Not having to wait for the user to instantly trigger the correct flags and load the required data on the spot my design runs faster than Microchips.
To sum up, while my design has the advantage of user friendliness and higher speed, Microchips definitely wins in terms of user control over the device. My device is a perfect design for hobbyists but not the best for hardcore professionals.
As for the SOC, it’s time to get some of it’s parts up and running. This week I wrote simple switches for the accelerator bus. I made two designs. The first one is the most simple multiplexer based switch you could think of. In this design I have three switches serving 2,4 or 8 devices. Based on the number of devices used by the user the suitable switch will be inferred.
The second design has only one version. Each module of this switch can accommodate two accelerators. The more the number of accelerators attached the more this modules of this switch need to be inferred to accommodate them. For example in the case of 5 accelerators 3 switches need to be inferred.
In the next week I would like explore more about using ISE optimization to eliminate unused modules. This can be a powerful tools in cleaning my SOC and customizing it based on the user needs.
0 Comments