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
"markp" <map.nospam@f2s.com> wrote in message news:<2vn75sF2o7m4kU1@uni-berlin.de>... > Hi All, > > I need to implement a low pass digital filter on 12 bit ADC data in a Spatan > IIE device, but I'd like it to be multiplier free - in other words just use > adders and bit shifting for the coefficients. The sample rate is 12Mhz and I > need a sharp cut-off at around 3MHz. Does anyone know of a simple design > (IIR?) to do this, or a website/tutorial to give me some pointers? I've seen > several websites with coefficient calculators, there are always a few > coefficients that can't be easily calculated with bit shifting and adding. > > Thanks! > > Mark. You didn't say how sharp your cutoff needs to be, or how much gain ripple you can tolerate. You might consider a pipelined multiplier design. This will result in very high clock rates, permitting one multiplier to handle 8-16 coefficients. Several multipliers can be used in parallel to increase the number of coefficients even further. Xilinx has numerous ap notes on digital filtering techniques. Here is a good review of the topic: http://www.andraka.com/multipli.htm This is probably the best book on the subject: http://www.amazon.com/exec/obidos/ASIN/3540413413/andraka/103-1626470-7551837 TomArticle: 75751
Monte Dalrymple wrote: > "Jim Granville" <no.spam@designtools.co.nz> wrote in message >>Interesting, Sounds a lot of work on the Z8000, can you elaborate on the >>reasons/needs for this core, in particular. >>Could also be a good example, for the OP. >> >>-jg >> >> > > > The original customer for this design makes air data computers, and projects > demand to continue well beyond when the "obsolete part stock" quantities of > the Z8000 will be around. Since the software for this system has to be FAA > certified, changing even one line of code is horrendously expensive. I'm > sure > that the OP was talking about exactly these kinds of applications. There are > a number of similar applications out there, because the Z8000 was the first > MIL-qualified 16-bit CPU and was designed into quite a few military and > mil-spec systems. These are the kinds of systems with very long lifetimes. I > know that the Z8000 was used in the F-15, the F-16, the 747 and the 757, > for example. All of these aircraft are still flying and are still in > production as > far as I know. These kinds of applications are the exact opposite of the > more > common "throw-it-away-in-18 months" that most people deal with today. ..and industrial systems are somewhere in-between. Did you need to get certification for the Z8000 SoftCPU ? - it seems this would need to be fully qualified as well, or have the MIL/FAA not quite caught up with the idea of SoftCPU ? -jgArticle: 75752
"Jim Granville" <no.spam@designtools.co.nz> wrote in message news:jdzld.1215$3U4.105563@news02.tsnz.net... > Monte Dalrymple wrote: > > > "Jim Granville" <no.spam@designtools.co.nz> wrote in message > >>Interesting, Sounds a lot of work on the Z8000, can you elaborate on the > >>reasons/needs for this core, in particular. > >>Could also be a good example, for the OP. > >> > >>-jg > >> > >> > > > > > > The original customer for this design makes air data computers, and projects > > demand to continue well beyond when the "obsolete part stock" quantities of > > the Z8000 will be around. Since the software for this system has to be FAA > > certified, changing even one line of code is horrendously expensive. I'm > > sure > > that the OP was talking about exactly these kinds of applications. There are > > a number of similar applications out there, because the Z8000 was the first > > MIL-qualified 16-bit CPU and was designed into quite a few military and > > mil-spec systems. These are the kinds of systems with very long lifetimes. I > > know that the Z8000 was used in the F-15, the F-16, the 747 and the 757, > > for example. All of these aircraft are still flying and are still in > > production as > > far as I know. These kinds of applications are the exact opposite of the > > more > > common "throw-it-away-in-18 months" that most people deal with today. > > ..and industrial systems are somewhere in-between. > > Did you need to get certification for the Z8000 SoftCPU ? - it seems > this would need to be fully qualified as well, or have the MIL/FAA > not quite caught up with the idea of SoftCPU ? > -jg > I am not sure of the specifics, because the customer took this responsibility. I suspect that the hardware certification process is easier than the software certification process. I saw a copy of the procedure used for software certification and I don't know how anyone could actually get any code written in a finite amount of time following the procedure. But then, I'm a hardware guy. I do know that the customer found my testbench to be very useful. As I mentioned in an earlier post, it checked every instruction, flag, register combination, addressing mode and boundary condition. The customer ran it with a real chip and my design and compared the results. Then I modified my design to match the chip where there was a difference. The only things I didn't match was the interrupt acknowledge timing and the execution time for multiply and divide. My design used fewer clocks, and the customer was satisfied with this result. MonteArticle: 75753
Monte Dalrymple wrote: > "Jim Granville" <no.spam@designtools.co.nz> wrote in message <snip >>Did you need to get certification for the Z8000 SoftCPU ? - it seems >>this would need to be fully qualified as well, or have the MIL/FAA >>not quite caught up with the idea of SoftCPU ? >>-jg >> > > > I am not sure of the specifics, because the customer took this > responsibility. > I suspect that the hardware certification process is easier than the > software > certification process. I saw a copy of the procedure used for software > certification and I don't know how anyone could actually get any code > written in a finite amount of time following the procedure. But then, I'm a > hardware guy. I do know that the customer found my testbench to be > very useful. Testbenchs are always under appreciated. > As I mentioned in an earlier post, it checked every > instruction, > flag, register combination, addressing mode and boundary condition. The > customer ran it with a real chip and my design and compared the results. > Then I modified my design to match the chip where there was a difference. > The only things I didn't match was the interrupt acknowledge timing and > the execution time for multiply and divide. My design used fewer clocks, > and the customer was satisfied with this result. An impressive case-study. Did they use an ASIC, or an FPGA (which?), and has that needed process revision yet ? -jgArticle: 75754
> > I am not sure of the specifics, because the customer took this > > responsibility. > > I suspect that the hardware certification process is easier than the > > software > > certification process. I saw a copy of the procedure used for software > > certification and I don't know how anyone could actually get any code > > written in a finite amount of time following the procedure. But then, I'm a > > hardware guy. I do know that the customer found my testbench to be > > very useful. > > Testbenchs are always under appreciated. Indeed. > > > As I mentioned in an earlier post, it checked every > > instruction, > > flag, register combination, addressing mode and boundary condition. The > > customer ran it with a real chip and my design and compared the results. > > Then I modified my design to match the chip where there was a difference. > > The only things I didn't match was the interrupt acknowledge timing and > > the execution time for multiply and divide. My design used fewer clocks, > > and the customer was satisfied with this result. > > An impressive case-study. Did they use an ASIC, or an FPGA (which?), > and has that needed process revision yet ? > -jg > The target was an Actel FPGA. It hasn't gone through a process revision yet that I am aware of.Article: 75755
Monte Dalrymple wrote: >> > I am not sure of the specifics, because the customer took this >> > responsibility. >> > I suspect that the hardware certification process is easier than the >> > software >> > certification process. I saw a copy of the procedure used for software >> > certification and I don't know how anyone could actually get any code >> > written in a finite amount of time following the procedure. But then, > I'm a >> > hardware guy. I do know that the customer found my testbench to be >> > very useful. >> >> Testbenchs are always under appreciated. > > Indeed. Agree. I only test my hobby project with a few settings and pray that everything else works. Did you try Zilog 16C01/16C00 (CMOS version Z8000)? Did you find any difference between Z8000 and 16C00? vax, 9000Article: 75756
Hi, I am trying to implement a system for video segmentation on xilinx FPGAs. The application need raw RGB stream data from a video camera and process it on FPGAs in real-time. Since using 24 pins(8 bits for each color) is not a wise way to hook up cemera with an FPGA, I was wondering what is usually done in such cases. About the camera, I will get it from a company, and they promise they could provide any type of camera I will need. HongtuArticle: 75757
In article <7ayld.565$a83.316@newsfe3-win.ntli.net>, "Kryten" <kryten_droid_obfusticator@ntlworld.com> writes: |> Always read the small print though. |> |> Several 6502 cores have been published but most of them come with notes |> about not being completely finished. For example, BCD instructions missing. Next thing is, that mostly all 6502 cores I've seen so far emulate the 65C02. For quite a number of legacy stuff which exploited the NMOS 6502 illegal opcodes for timing reasons a 65C02 is plain unusable. RainerArticle: 75758
"Rainer Buchty" <buchty@atbode100.informatik.tu-muenchen.de> wrote in message news:cn7jhc$19bkr$1@sunsystem5.informatik.tu-muenchen.de... > Next thing is, that mostly all 6502 cores I've seen so far emulate the > 65C02. > For quite a number of legacy stuff which exploited the NMOS 6502 illegal > opcodes for timing reasons a 65C02 is plain unusable. Daniel's T65 can be configured as either. :-) It can't do the Atari "sally" variant yet, but I imagine that most games writers would want their code to run on the ordinary 6502 in old 800 machines as well. So code using 'sally' illegals would be even rarer than those using the usual illegals. I wonder what fraction of all code used illegal opcodes, and were they ever much use?Article: 75759
"vax, 9000" <vax9000@gmail.com> wrote in message news:cn6qnq$58c$1@charm.magnus.acs.ohio-state.edu... > Monte Dalrymple wrote: > > >> > I am not sure of the specifics, because the customer took this > >> > responsibility. > >> > I suspect that the hardware certification process is easier than the > >> > software > >> > certification process. I saw a copy of the procedure used for software > >> > certification and I don't know how anyone could actually get any code > >> > written in a finite amount of time following the procedure. But then, > > I'm a > >> > hardware guy. I do know that the customer found my testbench to be > >> > very useful. > >> > >> Testbenchs are always under appreciated. > > > > Indeed. > > Agree. I only test my hobby project with a few settings and pray that > everything else works. > > Did you try Zilog 16C01/16C00 (CMOS version Z8000)? Did you find any > difference between Z8000 and 16C00? > > vax, 9000 As far as I know, the comparison was only done with the Z8000. However, I am pretty sure that the CMOS conversion at Zilog was done directly from the schematics, so the devices would be identical. As an aside, it's amusing to look at the Zilog website for a description of the 16C0X. It starts off with "RISC-like load/store architecture"... The Z8000 is classic CISC and is not anywhere near being load/store. The only thing RISC-like about it is the fact that the instruction set is quite regular.Classic marketing.Article: 75760
Austin, thanks. Absolutely most useful information. Thanks also for making such a clear statement. However, concerning SI, I can assure you that you are preaching to the converted. I was just asking because I have a number of low-rate control signals which have more than enough time to settle. Of course this doesn't reduce ringing, so I'm going to use series resistors at any output driving towards the FPGA. Thanks again Gunter "Austin Lesea" <austin@xilinx.com> wrote in message news:cn0e31$ruh1@cliff.xsj.xilinx.com... > Gunther, > > To connect two fpgas together, one should use the proper standard. > > LVDCI works, as does LVCMOS 6 mA (no external resistors required) with no > simulations (as they are both 50 ohms and will match almost any pcb trace > well enough). > > Any other standards require some SI engineering. > > The Virtex II family uses 0.35u IO, and they are intrinsically protected > by the ESD structures. You can not break them with overshoot and > undershoot. But you can create functional problems, and even change BRAM > and config bit contents if you slap the substrate silly with currents! > > The Virtex II Pro, S3, and V4 families uses faster 0.25u transistors, and > the reliabily is affected if the IO pin is forced to a voltage below > ground (> 4.05V stress on the pmos output transistor = Vcco - undershoot < > 4.05V). This is detailed in the data sheet under the abs max stresses. > > Not paying attention to signal integrity is just playing 'Russian > Roulette' with more than one chamber loaded -- very risky business. > > Austin > > > Gunter Knittel wrote: >> Austin, >> >> thanks very much for your answer. It's in a sense good to know that >> the simulation seems to be accurate - despite the fact that we then >> have to worry more about signals and spend more real estate for >> terminations. >> What makes me wonder, though, is that the simulations also said that >> one cannot even connect two FPGAs directly without violating >> undershoot limits - this doesn't reflect reality. >> What I really would like to know is whether or not I can damage >> the 2V4000 chip with strong over/undershoot. You said that the >> clamp diodes will withstand that stress, but what about the >> MOS transistors? The voltage across the gate oxide might become >> too large if excessive current causes a large voltage drop across the >> clamp diodes. I couldn't find anything on this topic in the VII-docs. >> Can you shed some light on this? >> >> Thanks very much >> Gunter >> >> >> "Austin Lesea" <austin@xilinx.com> wrote in message >> news:cmtdif$ru81@cliff.xsj.xilinx.com... >> >>>Gunter, >>> >>>The protection diodes are clamping the overshoot and undershoot. They >>>will not be damaged, but your signal integrity is terrible, you will have >>>excessive jitter, and that may lead to bit errors, and other behavior >>>that you will not like at all. >>> >>>I doubt the simulation is pessimistic, as I get the same results, and >>>often worse when too strong a driver is used unterminated. >>> >>>I suggest a small series resistor at the driver to better match the >>>lines. Perhaps somewhere from 22 ohms to 43 ohms. Simulate until you >>>have the best choice for the slow/weak and fast/strong IBIS model >>>corners. >>> >>>Oh, and thank you for using IBIS before you built the board. We are >>>happy (and you are happy) when you fix problems before the board layout. >>> >>>Austin >>> >>>Gunter Knittel wrote: >>> >>> >>>>Hi, >>>> >>>>I'm planning to use ALVCH-Transceivers located 4-8 inches away from a >>>>2V4000 FPGA. >>>>The board impedance is said to be 50R. I used IBIS models for both >>>>the transceiver and the FPGA (LVCM316S), and simulated one wire using >>>>PSPICE. The line is not terminated in any way. >>>>I get serious overshoot (>4V at 3.3V VCCO) and undershoot (-1V) >>>>at the (tri-stated) input of the FPGA. Current reaches 100mA during a >>>>short spike, otherwise some 50mA. >>>>My question: is this tolerable? >>>>Doc for VII-Pro states that the FPGA would suffer damage (gate oxide >>>>breakdown). >>>>Could it be that the simulation is too pessimistic in these cases? >>>> >>>>Thanks for any help >>>>Gunter >>>> >>>> >>Article: 75761
Jason Berringer wrote:
>
> Rick,
>
> That sounds like the approach that I was considering, as the reads seem to
> be okay, it's the writes that become unstable, however if I am delaying the
> write strobe, then I must also delay the data lines, and the address lines,
> otherwise the micro has moved on to the next cycle without the data being
> written correctly. It would seem to me that I must pipeline the write
> transfer to eliminate the instability.
You only need one level of registers or latches for the write data and
either address or decoded address. You are guaranteed two rising edges
of the 100 MHz clock in each period of the 40 MHz clock. So you just
need to delay the write strobe by one clock cycle and the write strobe
will be settled. So use that second clock edge to register the
non-timing info (data address...).
just make or just miss clock edge or even was metastable
V
write -----------_________________________----
clock -----_____-----_____-----_____-----_____
data,etc ==========xx=======================xx===
^ ^
register data,etc here | or here |
You can see, either way the data and address are grabbed correctly.
On my design, I took advantage of the delay to predecode the addresses
into separate control strobes removing one level of delay in the
subsequent logic.
--
Rick "rickman" Collins
rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.
Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
Article: 75762
rickman wrote:
>
> You only need one level of registers or latches for the write data and
> either address or decoded address. You are guaranteed two rising edges
> of the 100 MHz clock in each period of the 40 MHz clock. So you just
> need to delay the write strobe by one clock cycle and the write strobe
> will be settled. So use that second clock edge to register the
> non-timing info (data address...).
>
> just make or just miss clock edge or even was metastable
> V
> write -----------_________________________----
> clock -----_____-----_____-----_____-----_____
> data,etc ==========xx=======================xx===
> ^ ^
USE data,etc here | or here |
>
> You can see, either way the data and address are grabbed correctly.
>
> On my design, I took advantage of the delay to predecode the addresses
> into separate control strobes removing one level of delay in the
> subsequent logic.
I'm not sure I was awake when I wrote this. You don't actually need to
register the data,etc since they are stable long before and after your
enabled clock edge. Just use them before they go away which is
guaranteed to be a half clock cycle after the enabled clock edge.
--
Rick "rickman" Collins
rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.
Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
Article: 75763Jason Berringer wrote: > > Jim, > > Yes it does (XC2S200), but I have no access to the 40 MHz clock from the > micro, otherwise I would have implemented a synchronous transfer or used the > dual port RAM. I figured that without access to the 40 MHz clock the dual > port RAM would be out of the question since I would need a clock one the > second port which I do not have. Having the clock would not do you a lot of good anyway unless the micro specs the transfers relative to the clock, which is rare except for SSRAM or SDRAM interfaces. But you can use the rising edge of the write pulse as the clock to the BRAM. As long as it is a one way interface, you can provide your own clock to the read side on the other port. The micro won't be able to read what it has written though since you need a clock to read as well. But my other suggestion only requires that you delay the write/read strobes. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 75764
Hal Murray wrote: > > >And unless you have the time and inclination to figure out the internal > >timing for > >this kind of subsystem (a non-trivial task) you wil never be able to achieve > >cycle accuracy. A similar problem arises whenever you have more than one > >clock domain in the device, as the original synchronization strategy will be > >very > >difficult to discern. > > Why not? Old cycle times were slow by modern standards. Just add > enough delay to match the specs. You wouldn't need to *match* the timings, only meet them. You can always provide more setup time or allow less setup time from the peripheral. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 75765
Hi, I have a driver (244) with its OE-pins strapped to ground driving towards I/O-pins of a 2V4000 FPGA. I will make sure these are pure inputs once the configuration is loaded. I'm also aware of the fact that the FPGA tristates its IOs prior to configuration. All devices are connected to the same VCC, the 244 is never powered when the FPGA is not, and vice versa. My question is: what happens during Power-up (or Power-down)? Is it possible that the FPGA-IOs are damaged during power transition when the 244 is already (still) firing at full force? Any thoughts on this are appreciated. GunterArticle: 75766
In article <M7Lld.340$IM1.37@newsfe4-gui.ntli.net>, "Kryten" <kryten_droid_obfusticator@ntlworld.com> writes: |> I wonder what fraction of all code used illegal opcodes, and were they ever |> much use? On the C64 they were used quite often for fancy video manipulation; AFAIK they were also used within a floppy speeder to speed up GCR decoding. IIRC the mainly used ones were of the "do something and wire-or the accu in" kind and multi-cycle NOPs. You'll find a list here http://www.funet.fi/pub/cbm/documents/chipdata/6502-NMOS.extra.opcodes and how they map into the overall opcode table here http://www.funet.fi/pub/cbm/documents/chipdata/64doc RainerArticle: 75767
I don't think you will have a problem. As long the 244 have the correct output voltage levels. "Gunter Knittel" <knittel@gris.uni-tuebingen.de> wrote in message news:cn83s3$l7a$1@newsserv.zdv.uni-tuebingen.de... > > Hi, > > I have a driver (244) with its OE-pins strapped to ground driving > towards I/O-pins of a 2V4000 FPGA. I will make sure these are > pure inputs once the configuration is loaded. I'm also aware of the > fact that the FPGA tristates its IOs prior to configuration. > All devices are connected to the same VCC, the 244 is never > powered when the FPGA is not, and vice versa. > My question is: what happens during Power-up (or Power-down)? > Is it possible that the FPGA-IOs are damaged during power > transition when the 244 is already (still) firing at full force? > > Any thoughts on this are appreciated. > Gunter > >Article: 75768
> > I've coded for both and I really can't ever recall thinking that a > G3xx was anything like a 6845, so I am a bit surprised to see a > claim that they were "based" on them ! > I wasn't really trying to compare them in sense that this device could be used in place of that device. I was trying to show a time line of evolution from a pretty simple device to a more complex. I remember coming across the 6845 in devices that didn't require a high-end device like video terminals and arcade games. DerekArticle: 75769
There are a number of applications where old 8080 code or Z8000 has gone through significant number of code reviews and the logic is considered safe for some special applications. Nevertheless, having confidence in the softCPU is pretty important in order to have the qualify-by-similarity argument will hold. Something like an 8080 is a much simpler task to verify, but it cannot be ignored. Likewise, you really need to do some over-all system testing to insure subtle timing differences have not resulted in unexpected consequences. Just meeting/exceeding the timing of the original component is not good enough (IMHO) since there may be unknown dependencies on timing that might have been caught in the original qualification program. With respect to FAA certification, I believe RTCA DO-254 addresses some of these issues. -BH "Jim Granville" <no.spam@designtools.co.nz> wrote in message news:jdzld.1215$3U4.105563@news02.tsnz.net... > Monte Dalrymple wrote: > > > "Jim Granville" <no.spam@designtools.co.nz> wrote in message > >>Interesting, Sounds a lot of work on the Z8000, can you elaborate on the > >>reasons/needs for this core, in particular. > >>Could also be a good example, for the OP. > >> > >>-jg > >> > >> > > > > > > The original customer for this design makes air data computers, and projects > > demand to continue well beyond when the "obsolete part stock" quantities of > > the Z8000 will be around. Since the software for this system has to be FAA > > certified, changing even one line of code is horrendously expensive. I'm > > sure > > that the OP was talking about exactly these kinds of applications. There are > > a number of similar applications out there, because the Z8000 was the first > > MIL-qualified 16-bit CPU and was designed into quite a few military and > > mil-spec systems. These are the kinds of systems with very long lifetimes. I > > know that the Z8000 was used in the F-15, the F-16, the 747 and the 757, > > for example. All of these aircraft are still flying and are still in > > production as > > far as I know. These kinds of applications are the exact opposite of the > > more > > common "throw-it-away-in-18 months" that most people deal with today. > > ..and industrial systems are somewhere in-between. > > Did you need to get certification for the Z8000 SoftCPU ? - it seems > this would need to be fully qualified as well, or have the MIL/FAA > not quite caught up with the idea of SoftCPU ? > -jg >Article: 75770
There are one OPB-CENTRAL-DMA available in the EDK IP core list, while when you add this core to the system,no corresponding library file/directory generated for the software development,as described in <Xilinx-Driver>. While in <Xilinx-Driver>,there is one multi-channel-DMA,but core is not listed in the IP core list. So in this case,how can I take advantage of DMA in my design? Thanks!Article: 75771
<snip> > > OK, done, I think. > > John Thanks John. I'm not really sure how to tweek this for my system, but very interesting stuff nonetheless. I decided in the end to go for a 'rolling average' type filter (rectangular) with 16 taps, and this seems to be working quite nicely so I think I'll stick with this. Regards, Mark.Article: 75772
"Ken" <aeu96186@NOSPAM.yahoo.co.uk> wrote in message news:cn69m5$rme$05$1@news.t-online.com... > > I need to implement a low pass digital filter on 12 bit ADC data in a > > Spatan > > IIE device, but I'd like it to be multiplier free - in other words just > > use > > adders and bit shifting for the coefficients. The sample rate is 12Mhz and > > I > > need a sharp cut-off at around 3MHz. Does anyone know of a simple design > > (IIR?) to do this, or a website/tutorial to give me some pointers? I've > > seen > > several websites with coefficient calculators, there are always a few > > coefficients that can't be easily calculated with bit shifting and adding. > > Hi Mark, > > I can help you out with this by automatically generating VHDL for an FIR > implementation for your filter that uses shifts and adds. > > Please post the following details: > > > Do you want the filter to run at 12MHz (i.e. full-parallel) or do you have a > faster clock available that could be used to share hardware over multiple > clock cycles? > > Is the filter single-rate or are you decimating? > > Input bit-width? > > Signed/unsigned input? > > Quantised filter coefficients (integers ideally but fixed-point will do) or > more detailed spectral requirements (what -dB gain at 3MHz, pass-band ripple > etc., start rolling off at what freq, stop rolling of at what freq. etc.) > > > Cheers, > > Ken Hi Ken, Well I've gone for a rolling average filter at the moment, but the specs are: > Do you want the filter to run at 12MHz (i.e. full-parallel) or do you > have a faster clock available that could be used to share hardware > over multiple clock cycles? I've got a 65MHz clock and currently dividing by 6 to give 13MHz. > Is the filter single-rate or are you decimating? Single rate so far. > Input bit-width? 12 bit ADC data. > Signed/unsigned input? Unsigned. > Quantised filter coefficients (integers ideally but fixed-point will > do) or more detailed spectral requirements (what -dB gain at > 3MHz, pass-band ripple etc., start rolling off at what freq, stop > rolling of at what freq. etc.) -3db @ 3MHz, 4th order Butterworth type roll-off ideally, unity gain otherwise. Thanks! Mark.Article: 75773
"Tom Seim" <soar2morrow@yahoo.com> wrote in message news:6c71b322.0411131750.5b2c5534@posting.google.com... > "markp" <map.nospam@f2s.com> wrote in message news:<2vn75sF2o7m4kU1@uni-berlin.de>... > > Hi All, > > > > I need to implement a low pass digital filter on 12 bit ADC data in a Spatan > > IIE device, but I'd like it to be multiplier free - in other words just use > > adders and bit shifting for the coefficients. The sample rate is 12Mhz and I > > need a sharp cut-off at around 3MHz. Does anyone know of a simple design > > (IIR?) to do this, or a website/tutorial to give me some pointers? I've seen > > several websites with coefficient calculators, there are always a few > > coefficients that can't be easily calculated with bit shifting and adding. > > > > Thanks! > > > > Mark. > > You didn't say how sharp your cutoff needs to be, or how much gain > ripple you can tolerate. You might consider a pipelined multiplier > design. This will result in very high clock rates, permitting one > multiplier to handle 8-16 coefficients. Several multipliers can be > used in parallel to increase the number of coefficients even further. > Xilinx has numerous ap notes on digital filtering techniques. Here is > a good review of the topic: > http://www.andraka.com/multipli.htm > This is probably the best book on the subject: > http://www.amazon.com/exec/obidos/ASIN/3540413413/andraka/103-1626470-7551837 > > Tom Thanks Tom! Interesting stuff. Mark.Article: 75774
Thanks! I'll have a look at this. Mark. "Antti Lukats" <antti@case2000.com> wrote in message news:cn5s6o$9di$05$1@news.t-online.com... > "markp" <map.nospam@f2s.com> wrote in message > news:2vn75sF2o7m4kU1@uni-berlin.de... > > Hi All, > > > > I need to implement a low pass digital filter on 12 bit ADC data in a > Spatan > > IIE device, but I'd like it to be multiplier free - in other words just > use > > adders and bit shifting for the coefficients. The sample rate is 12Mhz and > I > > need a sharp cut-off at around 3MHz. Does anyone know of a simple design > > (IIR?) to do this, or a website/tutorial to give me some pointers? I've > seen > > several websites with coefficient calculators, there are always a few > > coefficients that can't be easily calculated with bit shifting and adding. > > > > Thanks! > > depending what you need, one solution is very simple "digital integrator" > its doable with only shift and add, there is some appnote or something at > xilinx web, I used that in digital carrier frequency amplifier, and it did > give actually very good filtering (for my application at least). > > an example digital integrator source is appended > --------- > -- > -- 18 Bit Digital Integrator Feedback "multiplier" > -- constant 1 / 256 (fixed, no choices implemented) > -- Tested and working. > library IEEE; > use IEEE.STD_LOGIC_1164.ALL; > use IEEE.STD_LOGIC_ARITH.ALL; > use IEEE.STD_LOGIC_UNSIGNED.ALL; > > library work; > > entity integrator_18bit is Port ( > rst : in std_logic; > clk : in std_logic; > din : in std_logic_vector(17 downto 0); -- Input: 18 Bit Unsigned > INTEGER > k : in std_logic_vector(3 downto 0); -- multiplier select (not > implemented) > dout : out std_logic_vector(17 downto 0) -- Output: 18 Bit > Unsigned INTEGER > ); > end integrator_18bit; > > architecture Behavioral of integrator_18bit is > > signal acc : std_logic_vector(25 downto 0); > signal vi_minus_vo : std_logic_vector(25 downto 0); > signal vi_minus_vo_sign_extended : std_logic_vector(7 downto 0); > > begin > -- Microblaze "endian" conversion > dout(0) <= acc(25); dout(1) <= acc(24); dout(2) <= acc(23); dout(3) <= > acc(22); > dout(4) <= acc(21); dout(5) <= acc(20); dout(6) <= acc(19); dout(7) <= > acc(18); > dout(8) <= acc(17); dout(9) <= acc(16); dout(10) <= acc(15); dout(11) > <= acc(14); > dout(12) <= acc(13); dout(13) <= acc(12); dout(14) <= acc(11); dout(15) > <= acc(10); > dout(16) <= acc(9); dout(17) <= acc(8); > > -- Error Value > vi_minus_vo <= (din & "00000000") - acc; > -- Sign Extension for Error Value > with vi_minus_vo(25) select vi_minus_vo_sign_extended(7 downto 0) <= > "00000000" when '0', "11111111" when others; > > process (clk) begin > if (rst='1') then > acc <= "00000000000000000000000000"; > else > if (clk'event and clk='1') then > -- Accumulate > acc <= acc + (vi_minus_vo_sign_extended(7 downto 0) & vi_minus_vo(25 > downto 8)); > end if; > end if; > end process; > > end Behavioral; > >
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