Wow! pyfda goes up into the air :-) If you need fixpoint functionality and C support, it might be worth looking into the web based tool www.micromodeler.com as well (don't know about commercial licensing though).
@sp1nelson is currently developing a zero-phase IIR filter (a bit similar to the filtfilt procedure if I understand correctly), requiring new routines for calculation impulse and frequency response etc.
As the same problem is coming up when using fixpoint arithmetics or (maybe) complex valued filters I think this is a good point for a more general discussion:
What are your ideas for extending the code functionality without producing too much clutter? I'm not a software architect, so my ideas may not be very pythonistic or expandable:
As the same problem is coming up when using fixpoint arithmetics or (maybe) complex valued filters I think this is a good point for a more general discussion:
What are your ideas for extending the code functionality without producing too much clutter? I'm not a software architect, so my ideas may not be very pythonistic or expandable:
- Define a library with general design routines (impz, freqz, ...) which default to the scipy functions if possible and "detour" to new implementations depending on data types (float, complex, fixpoint) and / or parameter ranges (causal / non-causal poles/zeros) or keyword params ("myhdl", "sos", ...)
- The actual filter design class contains has methods for calculating the various reponses and formats. These could be imports from scipy or a common library or they could also be contained entirely in the class.
with the
myhdl.fixbv this should be fairly straight forward, currently we have a gsoc student working on the fixbv features and the backend compiler
we can currently use the
fixbv for the fixed-point analysis and coefficient generations but it will be quite a while before we can use it directly in the filter HDL implementations.
After some discussions I think using a wrapper (e.g. "impz()") around various functions ("impz_real(), impz_cmplx, impz_non_causal, ...") is probably the most lightweight and flexible approach. We only have to decide upon proper discriminators (maybe a mix of variable types, number of arguments and keyword arguments).
I will try and use this wrapper approach. For plot_hf, however, it is easy to only modify calc_hf service to handle causal and anti-causal coefficients. I will store the anti-causal poles/zeros, etc in a different place in the filter dictionary and can use them to generate the H plot (if they exist). I have to think a little more about plotting the impulse functions. But I hope it too doesn't require a huge change to the plot_impz function.
I am going to setup a gsoc project through FOSSi to work on the filters and test pyfda integration
@chipmuenk can you be the backup mentor?
@chipmuenk also, ORConf is in your neck of the woods this year, fall 2018. Would you be interested in giving a co-talk?
"neck of the woods" is relative
we (myhdl folks) have been trying to coordinate a time and place to meet, a conf. on ORConf makes the most sense
@cfelton This would be a great opportunity to meet you and some other people from the myhdl community in RL. Most likely I would have to pay for this myself, but flights are reasonable, AirBnB is cheap and I would like to visit Gdansk. Unfortunately, we may have a family meeting on the weekend of ORConf but that should be sorted out in the near future. Shall we try to do a Skype / Hangout video conference re GSOC?
@cfelton Yeah, I have to reconnect my webcam as well ;-) I am in CET (UTC+1), so it's 7 h later here. Today and for the next 2 days I'm working from home (except from some short intervals) , so you can pick a time. Is Hangouts ok? I just noticed I don't have Skype installed anymore.
I will write up a short description and send it to you before
the projects will be under the FOSSi gsoc, https://fossi-foundation.org/gsoc18-ideas.html
- The HDL tab only shows when myhdl is installed on the system with at least version 0.10
- The
hdl_specs.pyfile now dynamically loads filter design files (currently onlyhdl_df1.pyandhdl_df2.pyeach with its own UI, an image of the filter topology and the myhdl description of filter topology. The filter design files are more or less demo files to test error catching and the interaction between myhdl and pyfda without proper functionality. - The
hdl_specs.pyfile triggers HDL conversion (works for a biquad, although none of the UI information is used for conversion). Fixpoint simulation still throws an error (now "Simulation failed: Inappriopriate argument type:" )
Perhaps both of you could take a look (also at the error) and then we could start the discussion.
... installing / updating is easy:
conda install / update -c Chipmuenk pyfda orpip install pyfda -U .
@sriyash25, an exercise that could be useful, is for you to write down (document) all the arguments/parameters that should be passed to the hardware filter blocks from pyfda and what should be passed back.
I've no idea what was wrong with GitHub ... the latest released version is under "master", the latest (more or less) working version is in the "develop" branch. The graphics is missing intentionally to check try ... except. Do you also have problems with resizing the graphics (slow / jumpy)? I've also just noticed that filter loading / saving is more or less defunct due to several bugs. Working on that.
As for the parameters that will be needed to be passed to the hardware filter blocks we will need: Filter coefficients (b,a for IIR and b for FIR) and ‘word_format'. I noticed in the current implementation ‘sos' is also being passed to myhdl, it is obviously not necessary but in any case, will we need that too? Return parameters could be success / fail for synthesis, and an array ‘y’ for simulation. Let me know if I have missed something.
Also, I suppose the implementation can be done only for a particular order of filter? For example, second order systolic FIR. How will we go about implementation for different orders of filters?
Also, I suppose the implementation can be done only for a particular order of filter? For example, second order systolic FIR. How will we go about implementation for different orders of filters?
I agree with the coefficients and the word format (WI, WF) for different parts of the filter topology (e.g. input, output, accumulator). I'm building a dict that contains these informations, additionally I'm providing data on how to requantize data (saturation or wrapping, truncation or fix() etc).
For IIR filters we will need coefficients in SOS format to obtain stable filters. One of the main advantages of using myHDL over a simple templating approach is that we have the power of python at hand: The fixpoint implementations should be intelligent enough to create topologies depending on the filter order. @cfelton : You have developed myHDL descriptions like this, haven't you?
Return parameters: sounds good to me.
Sriyash,
waiting for a month for a board wouldn't be a problem IMHO as you have to start with interface definition and high level coding anyway.
You should use what works best for you,
but I think that uploading and running a bit file to an FPGA is optional, synthesizing / simulating HDL code in Vivado is the important part. Verifying correct performance
waiting for a month for a board wouldn't be a problem IMHO as you have to start with interface definition and high level coding anyway.
You should use what works best for you,
but I think that uploading and running a bit file to an FPGA is optional, synthesizing / simulating HDL code in Vivado is the important part. Verifying correct performance
What do you think about using Trello for