Restructuring hls writer
Created by: benjaminkreis
Here we can discuss restructuring hls_writer.py. Now that we are supporting so many layer types this code has gotten rather inelegant.
I chatted with @jmduarte and @thesps recently, and here are a few initial thoughts:
-
hls_writer expects a list of python dictionaries that hold the layer info extracted in keras-to-hls or pytorch-to-hls. For @sergojin's model with the output of one layer feeding into two following layers (#104 (closed)), we should add to this dictionary where the inputs are coming from rather than assume the ordering in the json. @jmduarte made the nice suggestion of making the list of dictionaries a dictionary of dictionaries so that we can access layers by a key such as an index or name rather than an index in a list. This will make it easier to find the input to a layer.
-
Currently hls_writer's outer loop is through the lines of template C++ files. It has an inner loop over layers at each place it needs (e.g. when including the weight files, when adding the layers in the top level, etc.). Perhaps it would be better to make the outer loop over the layers (ie the dictionary of layer dictionaries) and append python objects holding the C++ code (which we would dump to files at the end). @jmduarte points out that this would make adding new layer types easier because development would be more confined to one section of code.
-
A lot of the confusing logic in hls_writer is in the sharing between layers of the
#define
parameters in parameters.h. This makes the generated C++ code easier for a human to read, but is making hls_writer harder to write because we have to write out every possible combination. For example, when making a dense layer, we check which layer came before to decide if we want to write n_in as a function of a previous Conv2D output (n_in = OUT_HEIGHT*OUT_WIDTH*N_FILT
), a previous Conv1D output (n_in = Y_OUTPUTS*N_FILT
), or a previous dense output (n_in = N_LAYER_1
). Maybe we can still use#define
parameters set by info only from the present layer dictionary (assuming this can be extracted from the json and h5), sometimes leading to redundant ones created in the next. This would keep some of the readability but avoid having to code the logic to explicitly handle every possible combination in hls_writer.