the API to pyfda will be provided by these objects and they can be coded here https://github.com/cfelton/filter-blocks/tree/master/filter_blocks/fda
Only had the time for a quick look: Looks clear & good, I would only suggest handling the float -> integer conversion of coefficients in pyfda so that the user can make a first estimation whether coefficient quantizations has an disastrous effect. It would also be nice if quantization parameters (e.g. accumulator wordlength and requantization method like floor, fix etc) could be controlled via the ui.
Currently, I'm developing in the branch 'hdl_interface', I've renamed the directory with the fixpoint implementations and some files and I'm in the process of redesigning where and how pyfda looks for user files at startup. Perhaps you can take a look before I merge some time next week.
one idea is to have a class that can be used to set all the parameters
from ..fir import filter_fir_df
class FIRFilter(HardwareFilter):
def __init__(self, b):
self.filter_type = 'direct_form'
self.n_cascades = 0
def set_cascade(self, n_cascades):
self.n_cascades = n_cascades
@hdl.block
def filter_block(self, glbl, sigin, sigout):
# this elaboration code will select the different structure and implementations
if self.filter_type == 'direct_form':
if self.direct_form_type == 1:
# all filters will need the same interface ports, this should be do able
dfilter = filter_fir_df
if self.n_cascades > 0:
filter_insts = [None for _ in range(self.n_cascades)]
for ii in range(self.n_cascades):
filter_insts[ii] = dfilter(
glbl, sigin[ii], sigout[ii]
)
else:
filter_inst = dfilter(...)
there are a lot of details missing
this api will take some experimentation to figure out
these objects would live in
filter_blocks/fda/fir.py, filter_blocks/fda/iir.py etc.
- setting (and maybe getting) parameters like internal and external word formats or coefficients. I suggest a setter method with **kwargs
- fixpoint simulation stuff
- HDL synthesis stuff
- maybe information on internal quanization noise on an algorithmic / behavioural level etc.
My next step would be to think about a way for importing data from fixpoint simulation.
I suggest the following discussion topics for tomorrow:
State / progress of the project
Import mechanism pyfda <-> myhdl
- File / directory structure: How do we organize the myhdl and UI descriptions
- Who you're gonna call: Communication between myhdl and pyfda
Interfaces for fixpoint simulations: input data, number of points, output format ...
Fixpoint filter implementations: next steps
- Integration into the myhdl ecosystem
A brief summery of the discussion
- Import mechanism pyfda <-> myhdl
We will have multiple classes for different filter implementations inheriting from whichever class appropriate. Base classFilterHardware.
Pyfda will import class as follows:from filter_blocks.fda import FIRFilter
parameters can be set and simulation run as follows:hdlfilter = FIRFilter() hdlfilter.set_coefficients(b) hdlfilter.run_sim() y = hdlfilter.get_response() - #55 (issue) demo of fixpoint simulation to be carried out for the fir_df1 filter. Output would be returned as a numpy array.
- Rounding modes support (ceiling, floor etc.) has to be provided in filter-blocks repo
- further discussion on limiting wordlengths based on FPGA family for optimal use of resources, providing warnings if wordlength is not ideal.
I may have missed some points
adding the import to the code example
from filter_blocks.fda import FIRFilter
hdlfilter = FIRFilter() # Standard DF1 filter
hdlfilter.set_coefficients(b) # Coefficients for the filter
hdlfilter.set_stimulation(x) # Set the simulation input
hdlfilter.run_sim() # Run the simulation
y = hdlfilter.get_response() # Get the response from the simulation
note, on the pyfda side, the simulation should probably run in a separate thread or subprocess
@chipmuenk , @cfelton So far, I was using a tool called gtkwave to view the waveform and verify outputs of simulation. I had written small test benches to pass parameters to the filter block and trace the signal. The test bench would output a .vcd file which can be viewed using the tool mentioned. here is the test bench for fir_df1: https://github.com/cfelton/filter-blocks/blob/master/tests/test_fir/test_df1.py . Of course, this code will not be necessary once the parameters are being passed from PyFDA, but I suppose for now , we still want output the .vcd file to verify simulation results?
in the
filter_blocks package we want to automated tests for everything, 100% tested
the tests will need to be self checking.
you could do something like an impulse input and verify the impulse out (for the fir will be the coefficients)
or you can verify the response for a subset of filters
same that exists now
hdlfilter.config_sim(trace=True)
that is a debug option, generally shoudn't be needed.
Hello, my name is Animesh Srivastava. I am a 4th Year student from NIT Hamirpur, India from Electronics and Communication Branch. I am looking forward to contribute to pyFDA. I have an experience of 2 years working with Python Language and Verilog. I am open to learn new skills and develop my prowess. I believe that my experience will help me to work on this project. Please guide me with the initial task to move on with it. Regards.
thanks for your interest in the pyfda project, @animeshsrivastava24 ! Unfortunately, I'm really busy at the moment, I haven't even managed to fully merge Sriyash's work until now. I'm afraid I won't find any time for pyfda related activities till the end of the year. I'm planning to better integrate @sriyash25 's and @cfelton 's contributions to myhdl / pyfda integration in the quiet time between Xmas and mid of January, your expertise would be highly welcome then.