Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Weiss <100383@embeddedrelated> wrote: >>For some applications, 10 seconds may be enough. But in others >> you would want to see an entire 24h period, looking for rate >> variations and other abnormalities. >>And resolution? 8-bit may be enough in some applications to send to send >>the filtered result. Aquisition is often done at 24-bit, but this usually >>includes a large DC offset. I am pretty sure that 24 bits is too much. While I do record audio in 24 bits, I am already pretty sure that many of the bits are noise, such as from the amplifiers. There has to be a lot more noise in the EKG signal. > Exactly, this algorithm is needed for those cases where you need > to record 24H worth of the signal, and then upload it, which > will take too much time with no or lossless compression. OK, but besides the time to upload, it will take too long for anyone to look at. The compression system will naturally have to find the similarities between cycles and factor them out. You also have to remove most below the thermal noise level, as that won't compress at all. So, what should be left is the difference between cycles, as a function of time, which should be exactly what one wants to know. > I just want to be clear about this, so basically, this algorithm > has to : > 1- Sample the ECG signal (Analog) to pick every cardiac cycle. Different cycles will have different lengths. Can that be factored out. (Resampled such that all have the same length? At the same time, storing the actual length.) Also, normalize the amplitude (vertical scale), again saving the actual values. (I don't know if either the period or amplitude are important in actual analysis.) > 2- Decompose every cardiac cycle signal using an orthogonal > polynomial base (Legendre polynomials for example). Comp.dsp people tend to like sinusoids, but other transforms are fine, too. I would first, after resampling and normalizing, compute the mean and subtract that from all of them. > 3- Save the more relevant coefficients of this decomposition, > it's the compression part. (These coefficients will be used > to recreate the signal) Seems to me that at this point, you need to know exactly the features that are actually important. The compression needs to explicitly extract those features on each cycle. Once that is done, it should be easy to show exactly how those vary over time, which is the only reason I can see for wanting 24h of data. > And all that must be done on an FPGA. > And about the comp.compression, i don't know which one you > are referring to, because i only found one Google group. There is a comp.compression usenet group, but comp.dsp might be a better choice. Why does it have to be on an FPGA? Not that it is a bad idea, but the exact reason can affect the best way to do the design. -- glenArticle: 156701
Hal Murray <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote: > In article <M-idnfszQIRIWA3OnZ2dnUVZ_tSdnZ2d@giganews.com>, > "Weiss" <100383@embeddedrelated> writes: > [ECG compression] >>And all that must be done on an FPGA. > Why? That seems like a poor approach. > It will be much simpler and cheaper to do it in software. Yes, but it could be done in a soft processor on the FPGA. I think by now a small (relatively) FPGA is cheaper than many other processors, along with the support circuitry needed. Especially if the hardware design needs to be done before the rest of the logic is spec'ed. (Or needs to be able to be easily changed for updates.) But I suspect it is a project for an FPGA class. I don't believe that should disallow soft processors. -- glenArticle: 156702
On 6/5/2014 5:17 PM, glen herrmannsfeldt wrote: > Hal Murray <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote: >> In article <M-idnfszQIRIWA3OnZ2dnUVZ_tSdnZ2d@giganews.com>, >> "Weiss" <100383@embeddedrelated> writes: > >> [ECG compression] >>> And all that must be done on an FPGA. > >> Why? That seems like a poor approach. >> It will be much simpler and cheaper to do it in software. > > Yes, but it could be done in a soft processor on the FPGA. > > I think by now a small (relatively) FPGA is cheaper than many > other processors, along with the support circuitry needed. I would not say it is cheaper for all cases. The devil is in the details. Yes, many things can be done in a soft core in an FPGA, but whether it is the best way depends on many factors. Before making any sort of judgement on this I'd like to know why the OP thinks the FPGA is needed. > Especially if the hardware design needs to be done before the > rest of the logic is spec'ed. (Or needs to be able to be > easily changed for updates.) > > But I suspect it is a project for an FPGA class. > > I don't believe that should disallow soft processors. Again, that depends. Let's hear the reasons and then discuss the validity or other options. -- RickArticle: 156703
>> But I suspect it is a project for an FPGA class. >> >> I don't believe that should disallow soft processors. > >Again, that depends. Let's hear the reasons and then discuss the >validity or other options. > >-- > >Rick Yes, it's a project, so i must use a compression algorithm based on orthogonal polynomials and it must be done on FPGA. In my opinion, it would have been better if i was able to use Matlab and do a software solution. Also, i'm not familiar with the mathematical portion of the project, and my knowledge on FPGAs is basic (from VHDL courses), that's why i'm trying to have some insight from more experienced people in the Electrical Engineering field. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 156704
Weiss <100383@embeddedrelated> wrote: (snip, I wrote) >>> But I suspect it is a project for an FPGA class. > Yes, it's a project, so i must use a compression algorithm based on > orthogonal polynomials and it must be done on FPGA. I like FPGAs for these problems, as you can get them to run very fast. You might be able to filter/compress input at 100MHz or so. But that is completely useless for a 300Hz input rate. > In my opinion, it would have been better if i was able to use > Matlab and do a software solution. You should still debug the algorithms in matlab before implementing them. Unless there are rules against it, I would do it with a soft processor inside the FPGA, along with the other logic needed for I/O. You need to interface with the A/D converter and whatever the data is going out through. > Also, i'm not familiar with the mathematical portion of the > project, and my knowledge on FPGAs is basic (from VHDL courses), > that's why i'm trying to have some insight from more > experienced people in the Electrical Engineering field. Well, as I said debug with matlab until you understand the math. You should have one sample data stream to work with. If you can't use a soft processor, my favorite way of doing these problems in FPGAs is with systolic arrays. There should be some literature on them. Othewise, see the suggestions from the previous post. -- glenArticle: 156705
On 6/5/2014 9:31 PM, glen herrmannsfeldt wrote: > Weiss <100383@embeddedrelated> wrote: > > (snip, I wrote) > >>>> But I suspect it is a project for an FPGA class. > >> Yes, it's a project, so i must use a compression algorithm based on >> orthogonal polynomials and it must be done on FPGA. > > I like FPGAs for these problems, as you can get them to run very > fast. You might be able to filter/compress input at 100MHz or so. > But that is completely useless for a 300Hz input rate. FPGAs also run slowly pretty well too, lol. >> In my opinion, it would have been better if i was able to use >> Matlab and do a software solution. > > You should still debug the algorithms in matlab before implementing > them. YES! No point at all in trying to implement an algorithm before you completely understand it and have it working in something like Matlab. At least that is the way we would do it on a work project rather than a school project. > Unless there are rules against it, I would do it with a soft > processor inside the FPGA, along with the other logic needed > for I/O. You need to interface with the A/D converter and whatever > the data is going out through. I don't agree with this. It is a level of abstraction that is likely not needed or useful unless there are problems fitting the logic into the FPGA. It also will be slow to simulate running a CPU emulation in the HDL simulator in essence. >> Also, i'm not familiar with the mathematical portion of the >> project, and my knowledge on FPGAs is basic (from VHDL courses), >> that's why i'm trying to have some insight from more >> experienced people in the Electrical Engineering field. > > Well, as I said debug with matlab until you understand the math. > > You should have one sample data stream to work with. Yes, your Matlab run will process the sample stream and produce identical results to the HDL simulation of your VHDL code. Then I suggest you design a way to run the same data through the FPGA to make sure it is working like the simulation. Finally connect your ADC(s) and process real data if that is part of your project. > If you can't use a soft processor, my favorite way of doing these > problems in FPGAs is with systolic arrays. There should be some > literature on them. A systolic array will in essence create a logic function for each operator in the algorithm and process one data sample through the pipeline on each clock. That may be overkill here, but I don't know what is involved in running this algorithm. Depending on the math needed, this may end up being a daunting project. -- RickArticle: 156706
In comp.arch.fpga, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: > Weiss <100383@embeddedrelated> wrote: > >>>And resolution? 8-bit may be enough in some applications to send to send >>>the filtered result. Aquisition is often done at 24-bit, but this usually >>>includes a large DC offset. > > I am pretty sure that 24 bits is too much. While I do record audio > in 24 bits, I am already pretty sure that many of the bits are > noise, such as from the amplifiers. There has to be a lot more > noise in the EKG signal. Oh yes, 24-bit is too much for the output. As I said, when sampling a DC coupled ECG at 24-bits, you sample a 10mV signal with a possible +/-1 Volt or so offset. That's 8 bits lost already. The remaining 16 bits will contain a lot of noise that requires filtering. But just cutting it down to 8 bits may be too much for some applications and certainly for some doctors. ;-) -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) The hardest thing is to disguise your feelings when you put a lot of relatives on the train for home.Article: 156707
In comp.arch.fpga, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: > Weiss <100383@embeddedrelated> wrote: > > (snip, I wrote) > >>>> But I suspect it is a project for an FPGA class. > >> Yes, it's a project, so i must use a compression algorithm based on >> orthogonal polynomials and it must be done on FPGA. > > I like FPGAs for these problems, as you can get them to run very > fast. You might be able to filter/compress input at 100MHz or so. > But that is completely useless for a 300Hz input rate. > >> In my opinion, it would have been better if i was able to use >> Matlab and do a software solution. > > You should still debug the algorithms in matlab before implementing > them. 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. -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) Save gas, don't use the shell.Article: 156708
On 06/06/14 01:20, Weiss wrote: >>> But I suspect it is a project for an FPGA class. >>> >>> I don't believe that should disallow soft processors. >> >> Again, that depends. Let's hear the reasons and then discuss the >> validity or other options. >> >> -- >> >> Rick > > Yes, it's a project, so i must use a compression algorithm based on > orthogonal polynomials and it must be done on FPGA. 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. > > In my opinion, it would have been better if i was able to use Matlab and do > a software solution. > > Also, i'm not familiar with the mathematical portion of the project, and my > knowledge on FPGAs is basic (from VHDL courses), that's why i'm trying to > have some insight from more experienced people in the Electrical > Engineering field. > > --------------------------------------- > Posted through http://www.FPGARelated.com >Article: 156709
David Brown <david.brown@hesbynett.no> wrote: > On 06/06/14 01:20, Weiss wrote: >>>> But I suspect it is a project for an FPGA class. >>>> I don't believe that should disallow soft processors. >>> Again, that depends. Let's hear the reasons and then discuss the >>> validity or other options. (snip) >> Yes, it's a project, so i must use a compression algorithm based on >> orthogonal polynomials and it must be done on FPGA. > 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). If the project was practice for something that needed real speed, then I would agree. > 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. 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. >> In my opinion, it would have been better if i was able to use >> Matlab and do a software solution. >> Also, i'm not familiar with the mathematical portion of the >> project, and my knowledge on FPGAs is basic (from VHDL courses), >> that's why i'm trying to have some insight from more >> experienced people in the Electrical Engineering field. 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. -- glenArticle: 156710
On 06/06/14 11:26, glen herrmannsfeldt wrote: > David Brown <david.brown@hesbynett.no> wrote: >> On 06/06/14 01:20, Weiss wrote: >>>>> But I suspect it is a project for an FPGA class. > >>>>> I don't believe that should disallow soft processors. > >>>> Again, that depends. Let's hear the reasons and then discuss the >>>> validity or other options. > > (snip) >>> Yes, it's a project, so i must use a compression algorithm based on >>> orthogonal polynomials and it must be done on FPGA. > >> 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). > > If the project was practice for something that needed real speed, then > I would agree. 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. > >> 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. > > 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. 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.Article: 156711
On Thu, 05 Jun 2014 14:32:37 -0500, Weiss wrote: >>For some applications, 10 seconds may be enough. But in others you would >>want to see an entire 24h period, looking for rate variations and other >>abnormalities. >> >>And resolution? 8-bit may be enough in some applications to send to send >>the filtered result. Aquisition is often done at 24-bit, but this >>usually includes a large DC offset. >> >>-- >>Stef > > Exactly, this algorithm is needed for those cases where you need to > record 24H worth of the signal, and then upload it, which will take too > much time with no or lossless compression. > > I just want to be clear about this, so basically, this algorithm has to > : 1- Sample the ECG signal (Analog) to pick every cardiac cycle. > 2- Decompose every cardiac cycle signal using an orthogonal polynomial > base (Legendre polynomials for example). > 3- Save the more relevant coefficients of this decomposition, it's the > compression part. (These coefficients will be used to recreate the > signal) > > And all that must be done on an FPGA. > And about the comp.compression, i don't know which one you are referring > to, because i only found one Google group. 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. -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 156712
On Thu, 05 Jun 2014 18:20:35 -0500, Weiss wrote: >>> But I suspect it is a project for an FPGA class. >>> >>> I don't believe that should disallow soft processors. >> >>Again, that depends. Let's hear the reasons and then discuss the >>validity or other options. >> >>-- >> >>Rick > > Yes, it's a project, so i must use a compression algorithm based on > orthogonal polynomials and it must be done on FPGA. > > In my opinion, it would have been better if i was able to use Matlab and > do a software solution. 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. > Also, i'm not familiar with the mathematical portion of the project, and > my knowledge on FPGAs is basic (from VHDL courses), that's why i'm > trying to have some insight from more experienced people in the > Electrical Engineering field. 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. -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 156713
David Brown <david.brown@hesbynett.no> wrote: (snip) >> If the project was practice for something that needed real >> speed, then I would agree. > 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 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. >>> 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". (snip, I wrote) >> To me, this is cheating much more than using a soft processor. (snip) > 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. 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. > 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. 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. -- glenArticle: 156714
Tim Wescott <tim@seemywebsite.really> wrote: (snip) > 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. 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. -- glenArticle: 156715
On 6/6/2014 3:23 AM, Stef wrote: > In comp.arch.fpga, > glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >> Weiss <100383@embeddedrelated> wrote: >> >>>> And resolution? 8-bit may be enough in some applications to send to send >>>> the filtered result. Aquisition is often done at 24-bit, but this usually >>>> includes a large DC offset. >> >> I am pretty sure that 24 bits is too much. While I do record audio >> in 24 bits, I am already pretty sure that many of the bits are >> noise, such as from the amplifiers. There has to be a lot more >> noise in the EKG signal. > > Oh yes, 24-bit is too much for the output. As I said, when sampling a > DC coupled ECG at 24-bits, you sample a 10mV signal with a possible > +/-1 Volt or so offset. That's 8 bits lost already. The remaining 16 > bits will contain a lot of noise that requires filtering. But just > cutting it down to 8 bits may be too much for some applications and > certainly for some doctors. ;-) 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? -- RickArticle: 156716
Now available from our Opencores.org repository a highly configurable Ethernet Switch for FPGA implementations. Check http://opencores.org/project,esoc for more details.Article: 156717
On 6/4/2014 4:21 PM, glen herrmannsfeldt wrote: > Mike Perkins <spam@spam.com> wrote: >> On 04/06/2014 11:15, hiluckydr@gmail.com wrote: >>> HI i am facing problem of 16 clock in my design although >>> planahead says only 8 clocks can be used > >> Why do you need 16 unrelated clocks in your design? > > Does seem pretty unusual. > >> Some more information is required. It is unusual to need 16. > > I can image a data multiplexer that takes 15 signals, each with > their own clock, and combines them into one output signal. If that is all it is doing, you likely don't need separate high speed clock routing for each, rather as the inputs come on chip they can be immediately synchronized to one system clock. >> There are techniques of creating enables from low speed clock >> edges that can be used to "eliminate" a clock from a design. > > There is special clock trees in most FPGAs to distribute low skew > clocks to large numbers of FFs. There might be some that need more > clocks, but don't need the low skew, and can use ordinary > routing for the rest. The skew is always a problem in FPGAs unless you can hand route the clocks. I am told the software will take care of dealing with the skew, the problem is when you have some amount of logic this gets to be a difficult task to manage if the clock routing is not used. I avoid that at all costs. -- RickArticle: 156718
Hi Guys,
I'm having a custom type in VHDL:
type alu_op_code is (
ALU_OP_IDLE,
...
);
Now having a testbench written in TCL i wawnt to force signals of type
alu_op_code.
How to actually do that?
For std_logic data this is possible usng:
force signal_name '0'
But how to use that with custom types?
Thank you in advance!
Cheers Robert
Article: 156719I'm a relative Verilog noob, and stuck on the following, not sure if I'm structuring the problem wrongly or if it's just a case of bad coding. BTW, this is not homework, I'm 40 years too old to be involved in that caper… There is a mode register and a man/auto switch. There's also a second input called Pump. The mode follows the switch, which is trivial, in addition, on posedge of Pump, the mode has to transition to auto. Hence, edge triggering is required. The applicable Verilog code is like this: input Switch ; // man/auto switch input Pump ; reg Mode ; always @ (posedge Switch) Mode <= 1 ; always @ (negedge Switch) Mode <= 0 ; always @ (posedge Pump) Mode <= 1 ; Here are the build errors (Quartus II) Error (10028): Can't resolve multiple constant drivers for net "Mode" at OWPump4.v(62) Error (10029): Constant driver at OWPump4.v(61) Any assistance really appreciated.Article: 156720
On 6/8/2014 12:08 AM, Bruce Varley wrote:
> I'm a relative Verilog noob, and stuck on the following, not sure if
> I'm structuring the problem wrongly or if it's just a case of bad
> coding. BTW, this is not homework, I'm 40 years too old to be involved
> in that caper…
>
> There is a mode register and a man/auto switch. There's also a second
> input called Pump. The mode follows the switch, which is trivial, in
> addition, on posedge of Pump, the mode has to transition to auto.
> Hence, edge triggering is required.
>
> The applicable Verilog code is like this:
>
> input Switch ; // man/auto switch
> input Pump ;
> reg Mode ;
>
> always @ (posedge Switch) Mode <= 1 ;
> always @ (negedge Switch) Mode <= 0 ;
> always @ (posedge Pump) Mode <= 1 ;
>
> Here are the build errors (Quartus II)
>
> Error (10028): Can't resolve multiple constant drivers for net "Mode"
> at OWPump4.v(62)
> Error (10029): Constant driver at OWPump4.v(61)
>
> Any assistance really appreciated.
I'm no expert in Verilog, I'm much more a VHDL guy. When I need to work
in it I have to pull out the books to refresh my memory of the syntax,
etc or I just pull up my previous code and review it. But I can see
what you are doing wrong easily.
Mode is a single variable which can only be assigned in one process...
(remember that I'm a VHDL guy so maybe this is wrong). You seem to have
three processes. The edge thing is for when you are defining a clocked
register, you refer to the edge of the clock. So it would be more like...
always @ (posedge clock)
if (Switch = 1) then
Mode <= 1;
else
Mode <= Pump;
end if;
I know this is not the correct syntax. Verilog is similar to C and uses
those curly braces in if statements and to define blocks of code.
Consider this to be pseudo code.
Do a little searching on the Internet and see what sort of text book or
lectures you can find. I know there is lots of good material on writing
VHDL. Also, it might help if you consider what the circuit would look
like in hardware and then learn how to describe that hardware in the HDL.
One other thing. For the above design you don't really need a register.
The man/auto switch acts as your memory element. You just need the
logic.
Mode <= Switch or Pump;
I hope this helps some. Sorry I couldn't be more sure of myself. Maybe
tomorrow I'll pull out a book and get the exact syntax.
--
Rick
Article: 156721Bruce wrote: > I'm a relative Verilog noob, and stuck on the following, not sure if > I'm structuring the problem wrongly or if it's just a case of bad > coding. BTW, this is not homework, I'm 40 years too old to be involved > in that caper? > There is a mode register and a man/auto switch. There's also a second > input called Pump. The mode follows the switch, which is trivial, in > addition, on posedge of Pump, the mode has to transition to auto. > Hence, edge triggering is required. > The applicable Verilog code is like this: > input Switch ; // man/auto switch > input Pump ; > reg Mode ; > > always @ (posedge Switch) Mode <= 1 ; > always @ (negedge Switch) Mode <= 0 ; > always @ (posedge Pump) Mode <= 1 ; edge triggered registers should look like always @(posedge clock) q <= d; d can be a complicated (combinatorial) expression. I like to put registers inside a module, just the register, then invoke that module, but you don't have to do that. You should only have one always @ assigning to the register output. -- glenArticle: 156722
Hi, your approach is typical digital-design textbook but it's completely wrong for an FPGA, sorry. It will work for a small example but it doesn't scale. On FPGAs, use synchronous logic. That means, information and the timing is separated. You have information signals and clocks. Edge triggering is done on clocks only. This matters because clock and information signals are physically separate on the FPGA and you cannot use one in place of the other. The problem is, generic Verilog tutorials, books etc aren't necessarily applicable to FPGA, because the language is more capable than the hardware. The same for digital design, the FPGA hardware dictates what you can do and (mostly) how it should be done. Here's how it should look instead: The task is to act on opening or closing switches - detect a transition of the switch signal. I use a "clk" signal that is available on every FPGA board, let's' say 100 MHz (or whatever) input wire switch; reg switch_prev = 0; wire switchOn = (switch & !switchPrev); wire switchOff = (!switch && switchPrev); reg pump = 0; always @(posedge clk) begin if (switchOn) begin pump <= 1; end if (switchOff) begin pump <= 0; end end You could read up on "Moore" (and "Mealy") machines as a starting point for synchronous logic design. Once I manage to formulate the task as Moore machine, an FPGA implementation is only a formality. It may seem abstract at first, but it's a straightforward path through the digital design "jungle". --------------------------------------- Posted through http://www.FPGARelated.comArticle: 156723
On Sat, 07 Jun 2014 16:18:50 +0200, Robert Schilling wrote: > Hi Guys, > > I'm having a custom type in VHDL: > > type alu_op_code is ( > ALU_OP_IDLE, > ... > ); > > Now having a testbench written in TCL i wawnt to force signals of type > alu_op_code. > > How to actually do that? I think this is why my testbenches tend to be in VHDL. If all else fails you can add a tedious but trivial VHDL wrapper to interface between everything-is-an-integer land and a decent type system. - BrianArticle: 156724
Does anyone know of a cheap 22V10 programmer ? or maybe a Atmel ATFxxxx programmer ?
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z