Finishing Inkscape Extensions

I continued working on the the Inkscape extensions that I started last week. I worked on improving and modifying some of the functions of the extensions to make the process of creating components graphics easier. But before that, we had to design and establish a naming convention for naming the components and their pins. Previously for our tests we created simple components manually, and thus we chose temporally names. However, now we are automatically generating an entire library, thus we need to standardize how names are created.

For each component, we have three files associated with it. These files are a C++ class, Verliog module definition, and JointJS element definition. We are using Fritzing fzb file as in input file. As I discussed previously, we are getting the pins names only from the fzb file. Now I will explain breifly the naming convention that we have developed. Please be noted that we will not be using this method, as next week we are going to modify it to be better and more convenient. Anyway, it is a good starting point to understand how we are generating the components.

component_files

The figure above shows the 2 files needed for a component, and its fzb file. The component used here is just an example to make understanding easier. However, the following explanation is general and can be applied to any component.

Verilog Module Definition

Modules can implement multiple protocols, and can have many pins for special functions. It is important for us to know what protocols each module uses so we can instantiate sub modules in Verilog to interface with the component. Other pins that do not have a protocol but have special functions such as “HOLD” or “RESET” are instantiated in Verilog as general pins input/output GPIO. Power pins such as “VCC” and “GND” are not considered in the Verilog module definition as these pins will not be connected to the FPGA. In our example above the module has 4 pins for SPI interface, and 2 pins for other functions, which are “HOLD” and “WP”. Hence, in our Verilog module we are instantiating 2 sub modules, MSPI and GPIO with 2 pins. The naming convention for submodules names is simply

m<module num>

where “module num” is an integer that starts at 0 for the first modules and increases by 1 for every subsequent module. In our example the MSPI has the name “m0” and the GPIO name is “m1”. The modules order is completely arbitrary.

The names for the input and outputs ports for the Verilog module are

m<module num>_<Verilog submodule port name>

For the example above, the first four ports are the MSPI ports, hence their names are m0_mosi, m0_sck, m0_ss and m0_miso. We are adding the module number as modules can have many submodules with the same functions, such as having 2 UART interfaces.

JointJS Element Definition

The JointJS file specifies the graphics for the component. Two data sets are contained in this file as well, pins names that the user sees, and Verilog names that are used for creating a UCF file. We are extracting the user friendly pins names from the fzb file. These names can be anything, and there is no specific naming convention used to name the pins. Names also differ between different components even if the pin has the same function such as being a ground pin. The other set of names, Verilog names should match the names in the Verilog module definition. Hence, it has the same naming convention

m<module num>_<Verilog submodule port name>

We can either write these names manually or extract them from the Verliog file. The problem with extracting the names then is matching these set of names to the appropriate pin with the friendly user name. Currently we are inputing the names manually, and for this reason next week we will be changing this naming convention to avoid the problem of entering the names manually.

You may also like...

Leave a Reply