ECG signals Compression/Decompression

IIRC there is a matlab module to create FPGA code from the matlab code. So develop in matlab, export to FPGA and done! But I guess there are some complications on that path. I think one of them is that you need to develop in integer in matlab. But that could of course be validated with a matlab FP model.

When you are looking for help with homework or a class project, please be up front about it. Tell us the requirements, say what you have done so far, and say exactly where you are stuck or need help or inspiration. No one here will do your project for you - but if you show that you are doing your best then you can get ideas and hints from experienced developers.

But if you don't make everything clear, then people (as now) discuss other ways to approach the problem - that might help you make a /real/ ECG monitor, but it won't help your project.

At a guess, if you are asked to do this in an FPGA then soft processors will be "cheating" (even though they might be a good choice in real life).

One idea that you might like to look at is MyHDL - this will let you use a high level language (Python) for the code, but it generates VHDL (or Verilog) and runs in "hardware" rather than "software". Your teachers might object because it is not "proper VHDL" - or they might like the creativity it shows.

(snip)

If the project was practice for something that needed real speed, then I would agree.

To me, this is cheating much more than using a soft processor.

Well, partly the things I like to do in FPGAs don't lend themselves to that style. Systolic arrays, very long piplines of fairly simple unit cells, running as fast as possible. Cells containing adders, comparators, and muxes, with pipeline registers as often as possible.

No-one said anything about my suggestion to resample such that all cycles are the same length (in samples). Also, I am not so sure how to do a resampler in FPGA.

-- glen

I think using a soft processor changes the domain of the problem too much - it becomes a software project rather than a hardware project. In a real-world project, you use whatever mixture of software and hardware makes most sense - but in a class project the aim is to learn about a particular technique.

MyHDL is not about using software instead of hardware in your FPGA - it is not like the C-to-FPGA converters that are now popular. You have to think in hardware - using pipelines, muxes, and whatever else you want. You get what you ask for, and nothing more. But you express it in Python rather than VHDL, which can make it easier to write - especially for more complex hardware. You get easy integration with a very powerful functional simulator, since you can write your simulations in Python. And you don't have to worry about the silliness VHDL has with using and converting between std_logic, boolean, integers, etc.

The biggest practical barrier is the word "relevant". What's relevant in an EKG? Coming up with a lossy compression scheme that is both efficient and leaves you with something useful is not something that could be done by a lone engineer, or even a lone engineer with a lone cardiologist standing by his shoulder.

The way you approach this sort of a problem is done in steps: first, make it work in Matlab by any means possible; then, make it work in Matlab using only operations that you know are easily available on your target (which, in this case, is your FPGA that's programmed from a description in VHDL); finally, implement your Matlab code in your target.

When I'm doing this sort of thing professionally, I'll often be going back and forth among the steps (Google for the "waterfall model" of project management). In addition, I'll often be responsible for steps 1 and 2, while my client will provide the engineer(s) who take my Scilab code or detailed algorithm document and work on step 3.

Then you need to do the separate steps all the more -- you don't want to be in a position where nothing works and you have no clue why. If you get the math working in Matlab and it doesn't work in the FPGA, then you know it's an implementation issue, not the math. If you can't get the math working in Matlab, then you know that there's no point in wasting time with HDL.

(snip)

Seems like it would depend on how much of the logic is in soft processor and how much isn't. But as I suggested before, if it is practice for a problem that can't be done in a processor, then it makes sense that it not be.

(snip, I wrote)

(snip)

Seems to me that, more and more, FPGAs are being used to replace big blocks of logic, including processors. In that sense, a C to FPGA converter that generates a processor to run compiled C code doesn't seem so useless.

As I might have written to many times now, my favorite FPGA problem is systolic arrays, but they look so different from serial implementations of algorithms, that it doesn't make sense to expect a compiler to figure it out.

Trying to think up an example of about the right complexity, say you have many 100x100 matrices in base 4 (that is, each entry is 0, 1, 2, or 3. You want to matrix multiply all of them, computing the result elements modulo 7, and find which one(s) have the most 6's in their product. (This may or may not be much help to the OP.)

It isn't hard to write the matlab to do a matrix multiply, loop over all combinations of inputs, compute the modulo 7 and count. In C, you can write the five nested for loops. The numbers were chosen, as I suspect the logic to compute the module 7 sum of the products of small numbers is fairly simple, and can be done in a nice pipeline. Now add one more complication: you need it for all cyclic permutations of the rows of the matrices. This last requirement makes the pipeline of the inner loop especially efficient. A simple table lookup for the products, and a nice simple (in logic) modulo 7 adder, makes the pipeline very simple. All the complication is getting the data into and the results out in the right order.

Sounds like the reason I use verilog instead of VHDL. Verilog also doens't have std_logic. Just bits to move around. Usually I can read VHDL well enough to work on problems with it, but I normally don't try to write it.

-- glen

(snip)

I think the 24 hours must be important here, in addition to the complications of compression.

The ones I usually see on TV shows take about 10 seconds. (Well, partly it is to get the drama right.) But that is the people who will be dead in minutes if they don't figure out what to do.

So, maybe there are some (small number) of cardiologists that know what to do with 24 hours of data, for some specific cases. (Obviously, ones that won't be dead in minutes.)

In that case, I am not so sure that a lone engineer and lone cardiologists couldn't do it.

An important part of compression is finding similarities in data, (such as repeats) and representing them only once in the output, and then finding the difference between those and the actual data.

Seems to me that the cardiologist will want to know those differences, and very little about the similarity. There will be a lot of thermal noise in the data, which, if the compression is to work well at all, will have to be removed (filtered).

As I mentioned before, I beleive you want to resample so each period is the same length (in samples). Seems to me that resampling it already a pretty good project.

Hmm... If you do the expansion in Legendre polynomials, integrating each over one period (Legendre polynomials are from -1 to 1) then that isn't so different from resampling. (As far as I can tell, the Legendre Transform is different from an expansion in Legendre polynomials.) So maybe there isn't a need for resampling.

But I don't know at all how many terms you need.

-- glen

Why would you need to DC couple an EKG signal? Just define the low end of the frequency range needed and AC filter the input. Then you can use a much less costly or complex ADC.

Just how large is a typical EKG signal anyway?