Hi everyone,

As part of a large FPGA/DSP project, I built a c extension library for python that mimicks the vhdl standard library fixed point functionality (https://github.com/smlgit/fpbinary). I did this because I wanted to use free tools for the job (rather than, say, Matlab). Now, I know that Chris Felton has a module for this, but I believe it was incomplete. I also wanted a really fast implementation (hence written in C).

My question is regarding the demand for such a library and the use of python for DSP simulation in general. Do any of you use free tools for your DSP work? Do you see merit in using python-based libraries (I asked a similar question on the scipy-user list and got no responses). It seems that in a world of open source software, it would be viable to do entire DSP projects without spending anything on design tools.

EDIT: I just found https://www.dsprelated.com/thread/3939/choice-betw... - seems like a few people have used python for DSP...

Thanks

sml.

Hi!I've been working last week with some dsp algorithms in DSP, and I've moved from fi objects in matlab to python. 

The only lib that I've found is this:

http://www.dilloneng.com/demodel.html

It's not complete but it's a good start.

Thanks a lot for the fpbinary!!!!

Hi federroux,

Yes, I recently became aware of demodel. It seems to do most of what people might want but it doesn't follow hardware environment semantics (like VHDL) as closely as I want. For example, there isn't a resize method and it looks like you have to convert to a float, round and create a new object for resizing. However, it certainly does look usable. Thanks for the reply.

sml.

This is extremely helpful. I've been a Matlab user for many years and the 'fi()' library is tremendously helpful in getting things done quickly avoiding stupid mistakes. However, it's very slow, and it's Matlab...

I started to use Python after moving to cocotb - a Python-based verification framework for FPGA/ASIC. Check it out here: https://github.com/potentialventures/cocotb/

The biggest thing I missed from Matlab was the python equivalent of 'fi()', which seems to be exactly what you have, even better/faster. This is useful when making a fixed-point model of the design for bit-accurate modeling. I think this should be a great addition to cocotb and should be directly included in their distribution.

I shared your post to the cocotb Gitter

https://gitter.im/cocotb/Lobby?source=all-rooms-list

Very interesting, I was not aware of this framework. Thanks a lot for the info - I'll look into this further!

Cheers for the reply.

Sml-

Everything "DSP focused" or DSP centric is slowly dying, thanks to TI's brain lock on AI.  Total disaster that is.

Deep learning is where you can get extremely good traction in Python related tools, especially if it's reduced precision and fast.  Both Intel and Nvidia have recently come out with new chips with SIMD (or Cuda cores) that get down to 8-bit fixed point.

Check out the Kaldi speech recognition group for example, not a day goes by that people are trying to figure out faster real-time.  All the big tech names are there, including Japan, China, Europe ... reminds me of DSP in the 1990s.  Advances are fast and furious, Nvidia guys working hard to keep up and support new things running on x86.  Same is true on image recognition groups.  But of course TI is nowhere to be found, I guess their executives just counting days to retirement or something.

-Jeff

Hi,

I use Python actively (forgetting even Matlab:) and found numpy/scipy libraries very decent and sufficient. Some info is here especially for DSP; https://docs.scipy.org/doc/scipy/reference/signal....

Your library could be very helpful for those who have vhdl/fpga projects. As you have stated, being free to use and presenting modern features with Jupyter notebooks makes Python a choice. Python grows especially by the contributions like you. 

I only suggest you to find other guys who are willing to contribute, that way it would be much more easier. 

Thanks for the reply. I have used the scipy signal package. My only criticism of it is it's pretty sparse. I guess that was the crux of my question - why hasn't it got a lot more features in it. My sense is that most people in signal processing are real engineers who are interested in using, not developing, tools - which I understand.