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
On Jul 29, 3:23=A0pm, "Pete Fraser" <pfra...@covad.net> wrote:
> I am working on a project where I need to
> implement 6-th order Butterworth low-pass
> filters in an FPGA. In some the bandwidth is
> low relative to the input data rate, whereas
> others have higher bandwidth. I can use ScopeIIR
> or Matlab to give me a good idea of coefficient
> accuracy for any given ratio of bandwidth to
> input sample rate.
>
> However, I'm not sure what data-path accuracy
> I need (for 20-bit input / output accuracy).
> Is there a rule-of-thumb I can use, or do I just
> have to simulate the filter with real data and
> see what gives me low enough noise?
>
> I was planning on using biquads, but I'm not sure
> whether I'm better off with DF1 or DF2 sections.
>
> Thoughts?
i think you'll do better with DF1 sections (it will cost you two more
storage states, you'll have 8 instead of 6) and, for each section, an
accumulator that is wide enough to have no error given the word widths
of the signal (you said 20 bits) and the coefficients (that might
depend on the range of coefficients).
using 1st-order error shaping, a.k.a. "fraction saving" might gain you
something, and you can accomplish this for free if you leave in your
accumulator (as an initial value) the long-word output from the
previous sample. you will need to compensate this by subtracting 1
from "a1", the first feedback coefficient. then, for rounding to the
next section, all you need to do is truncate the low-order bits of the
word going to the next section, no rounding necessary (that gets fixed
with the fraction saving). that means, for
H(z) =3D N(z)/D(z)
where
D(z) =3D 1 + a1*z^(-1) + a2*z^(-2)
=3D 1 + (a1+1)*z^(-1) - z^(-1) + a2*z^(-2)
the term z^(-1) would be the double wide output from the previous
sample, y[n-1].
if your biquads remain resonant (meaning complex conjugate poles) and
if the resonant frequency is going to be very low and if the resonance
will be high (that is the poles are close to z=3D1), then consider
reworking the denominator of the biquad transfer function as:
D(z) =3D 1 + a1*z^(-1) + a2*z^(-2)
=3D 1 + (a1+2)*z^(-1) - 2*z^(-1) + (a2-1)*z^(-2) + z^(-2)
for the terms 2*z^(-1) and z^(-2), you would use the double-wide
previous states of y[n-1] and y[n-2].
just a recommendation i might make to make your life easier in the
universe of fixed-point arithmetic.
> Thanks
FWIW.
r b-j
Article: 148526On Jul 29, 8:47=A0pm, spop...@speedymail.org (Steve Pope) wrote: > Pete Fraser <pfra...@covad.net> wrote: > >I am working on a project where I need to > >implement 6-th order Butterworth low-pass > >filters in an FPGA. In some the bandwidth is > >low relative to the input data rate, whereas > >others have higher bandwidth. I can use ScopeIIR > >or Matlab to give me a good idea of coefficient > >accuracy for any given ratio of bandwidth to > >input sample rate. > > >However, I'm not sure what data-path accuracy > >I need (for 20-bit input / output accuracy). > >Is there a rule-of-thumb I can use, or do I just > >have to simulate the filter with real data and > >see what gives me low enough noise? > > You should simulate the fixed-point filter. =A0When simulating, > you do not necessarily have to stimulate it with realistic data. =A0I > often will stimulate the design being tested with bandlimited noise, and > measure the RMS error of output (relative to the same design, but in full > floating-point). =A0Plotting the RMS error (in dBc) vs. RMS input level > gives you a very good idea of the dynamic range of the fixed point > design. > > >I was planning on using biquads, but I'm not sure > >whether I'm better off with DF1 or DF2 sections. > > You can do this, or you can use a lattice topology > (called "ARMA" in matlab/fdatool), which is the most > well-behaved topology. > > Steve I recently did just that and concurs with everything Steve said. Most important figure you need to keep track of is your I/O RMS with the various quantizations and casts you'd have applied. The places where casting occurs is of particular importance here and is structure- related. If your realization is sequential it'd be even harder to sort out. My final filter was DF2 with a shared biquad core and a memory trace for states and biquad inputs and outputs. The best performance for casting you get from convergent. Keep simulating various scenarios and look at your RMS and play with your structure, quantization, and castings until you land something satisfactory. Looking at my core's generics, here are what worked quite well for me: - core: rolled IIR DF2 SOS - sample word width: 16 - internal state width: 25 - internal fract width: 15 - coeff word width: 17 - coeff fract width: 15 - output scaling: YES Regards, -MomoArticle: 148527
Thank you for your fast answer. I'm using an Altera DE1 demo board with SDRAM A3V64S40ETP from Zentel. It's a normal 64Mbit chip with 4096 rows to be refreshed in 64ms. 4 banks x 1M x 16bit. The VHDL SDRAM controller I'm looking at is included in OneChip MSX core and it's clocked at 85Mhz. It's uses board PLL to manage clock skew (3ms). It's set in CL2, Single location access, burst length ONE and burst type sequential. Pratically it's only a byte READER/WRITER. No refresh commands are present during normal operations but only during initialization. Every operation is manager in 8 cycles. CAS latency is set to 2 BUT data are read after 3 cycles!!! 1) ACT/RAS 2) NOP 3) READA/CAS 4) NOP 5) NOP 6) DATA-READ 7) (precharge?) 8) (precharge?) Naturally single byte access is enough for the specific purpose but I was expecting different behavior (refresh commands and correct cycles for reads). Datasheet of this SDR SDRAM part indicates expected behavior and it's almost the same as ISSI. Thank you in advance for any support. I can provide you the source code to look at... Saverio >On Jul 29, 7:05=A0am, "siriokds" <siriokds@n_o_s_p_a_m.gmail.com> wrote: >> As a newbie I'm working on an SDR SDRAM controller in VHDL and looking at >> datasheet of the chip I read how to set CAS latency to 2. >> I'm just using only simple READA/WRITA (with autoprecharge) commands >> avoiding refresh/autorefresh ones. >> >> My answer is simple, >> >> Does "AutoPrecharged" commands (READA/WRITA) issue dram refresh also >> avoiding me to performs ALSO the refresh command? >> >> I've looked at OneChip MSX SDRAM controller and refresh command is used >> only during initialization ... >> >> Thanks in advance for any help! >> >> Saverio >> >> --------------------------------------- =A0 =A0 =A0 =A0 >> Posted throughhttp://www.FPGARelated.com > >Precharge and refresh are two different things. You can think of a >row of memory >haveing two operating states, Active, and Precharged. Issuing a row >activate >command places the row in the active state. Issuing a precharge >comand or >using a read or write with autoprecharge places the row in the >precharged state. > >The row must be active to perform read or write. > >All rows must be precharged before issuing auto-refresh commands. > >For SDR SDRAM you don't necessarily have to issue refresh at a >constant >rate because it doesn't have a DLL like the DDR parts. However you >must >meet the refresh rule that all rows are refreshed within the refresh >period >specified, usually 32 ms or 64 ms. This generally works out to an >average >of one auto-refresh command every 15.6 us for smaller parts or every >7.8 us >for the larger ones. > >Also for SDR SDRAM (but not DDR) you can effectively refresh the part >by performing row activates to all rows within the refresh period. >Note that >row activate works on one bank at a time, while auto-refresh works on >all four banks at once. So in effect it takes four times as many row >activates >to refresh the part. However there are some applications like video >buffer >memory where this much access would occur anyway and then you can >avoid using refresh commands altogether. > >If the controller you looked at doesn't perform auto-refresh cycles >after >initialization, it should either have a way to request a refresh cycle >once it is operational, or have some other method of making sure all >rows get refreshed (some controllers do "scrubbing" refresh consisting >of reading out data, performing error correction, and writing it >back). > >I seem to recall that Fujitsu had a good data sheet that showed a >state diagram of the SDRAM. But it's been a while since I first >looked at these parts and the whole thing has become ingrained >in my head since then. > >HTH, >Gabor > --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148528
On 07/29/2010 12:47 PM, Steve Pope wrote: > Pete Fraser<pfraser@covad.net> wrote: > >> I am working on a project where I need to >> implement 6-th order Butterworth low-pass >> filters in an FPGA. In some the bandwidth is >> low relative to the input data rate, whereas >> others have higher bandwidth. I can use ScopeIIR >> or Matlab to give me a good idea of coefficient >> accuracy for any given ratio of bandwidth to >> input sample rate. >> >> However, I'm not sure what data-path accuracy >> I need (for 20-bit input / output accuracy). >> Is there a rule-of-thumb I can use, or do I just >> have to simulate the filter with real data and >> see what gives me low enough noise? > > You should simulate the fixed-point filter. When simulating, > you do not necessarily have to stimulate it with realistic data. I > often will stimulate the design being tested with bandlimited noise, and > measure the RMS error of output (relative to the same design, but in full > floating-point). Plotting the RMS error (in dBc) vs. RMS input level > gives you a very good idea of the dynamic range of the fixed point > design. > >> I was planning on using biquads, but I'm not sure >> whether I'm better off with DF1 or DF2 sections. > > You can do this, or you can use a lattice topology > (called "ARMA" in matlab/fdatool), which is the most > well-behaved topology. > > Steve I did a quick search on "digital lattice filter" and didn't come up with any really coherent discussion. There was lots of stuff about how to use this or that lattice filter in this or that specialized application, but not "this is DF1, this is DF2, this is a digital lattice filter...". Got any references? -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.htmlArticle: 148529
On 07/29/2010 12:23 PM, Pete Fraser wrote: > I am working on a project where I need to > implement 6-th order Butterworth low-pass > filters in an FPGA. In some the bandwidth is > low relative to the input data rate, whereas > others have higher bandwidth. I can use ScopeIIR > or Matlab to give me a good idea of coefficient > accuracy for any given ratio of bandwidth to > input sample rate. > > However, I'm not sure what data-path accuracy > I need (for 20-bit input / output accuracy). > Is there a rule-of-thumb I can use, or do I just > have to simulate the filter with real data and > see what gives me low enough noise? > > I was planning on using biquads, but I'm not sure > whether I'm better off with DF1 or DF2 sections. What Vladimir and Steve said. If you want to know for sure, make a block diagram of the filter, put in summing junctions for the quantizers, then find the transfer function from that summing junction to the output. Do a Bode plot, and figure that your output noise will be your quantization noise times the worst-case gain. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.htmlArticle: 148530
Tim Wescott <tim@seemywebsite.com> wrote: >I did a quick search on "digital lattice filter" and didn't come up with >any really coherent discussion. There was lots of stuff about how to >use this or that lattice filter in this or that specialized application, >but not "this is DF1, this is DF2, this is a digital lattice filter...". >Got any references? A classical description of lattice filters is in Rabiner and Schafer, where they are called "lattice filters". But in the Mathworks world, they are called "ARMA filters", or sometimes "lattice ARMA" filters. Something like the Mathworks Filter Design Toolbox has a passable explanation of this topology. SteveArticle: 148531
On 30 Jul, 01:42, Tim Wescott <t...@seemywebsite.com> wrote: > On 07/29/2010 12:47 PM, Steve Pope wrote: > > > > > > > Pete Fraser<pfra...@covad.net> =A0wrote: > > >> I am working on a project where I need to > >> implement 6-th order Butterworth low-pass > >> filters in an FPGA. In some the bandwidth is > >> low relative to the input data rate, whereas > >> others have higher bandwidth. I can use ScopeIIR > >> or Matlab to give me a good idea of coefficient > >> accuracy for any given ratio of bandwidth to > >> input sample rate. > > >> However, I'm not sure what data-path accuracy > >> I need (for 20-bit input / output accuracy). > >> Is there a rule-of-thumb I can use, or do I just > >> have to simulate the filter with real data and > >> see what gives me low enough noise? > > > You should simulate the fixed-point filter. =A0When simulating, > > you do not necessarily have to stimulate it with realistic data. =A0I > > often will stimulate the design being tested with bandlimited noise, an= d > > measure the RMS error of output (relative to the same design, but in fu= ll > > floating-point). =A0Plotting the RMS error (in dBc) vs. RMS input level > > gives you a very good idea of the dynamic range of the fixed point > > design. > > >> I was planning on using biquads, but I'm not sure > >> whether I'm better off with DF1 or DF2 sections. > > > You can do this, or you can use a lattice topology > > (called "ARMA" in matlab/fdatool), which is the most > > well-behaved topology. > > > Steve > > I did a quick search on "digital lattice filter" and didn't come up with > any really coherent discussion. =A0There was lots of stuff about how to > use this or that lattice filter in this or that specialized application, > but not "this is DF1, this is DF2, this is a digital lattice filter...". > > Got any references? These filters are treated in medium / advanced level DSP books, like Proakis & Manolakis. Don't think the term 'lattice filter' is too common, though; rather 'lattice structure' or 'lattice ladder structure'. I am not sure they are worth a general discussion: The problem is that the lattice structure fuses both the FIR and its IIR inverse, so if the FIR has zeros on or outside the unit circle, the computations blow up. It makes a lot of sense keeping those disussion on a need to know basis. RuneArticle: 148532
Hi all, I have to interface DSP with 3 image sensor,s there're only two i2c GPIO for DSP, so I need to implement an i2c core in FPGA, I've implemented an i2c slave core to receive data from DSP and store them with a large LUT in my FPGA and another i2c master core in FPGA to send the stored i2c data to the 3 sensors, Now I'm wondering if I can use FPGA as an arbitration core, what the FPGA does is just to detect the start stop condition and the slave address, then directly transfer the data to the right sensor without storing in FPGA itself. I don't know which method is better, and how to implement the second method, could anyone give me some suggestion? ThanksArticle: 148533
On Jul 28, 5:47=A0pm, rickman <gnu...@gmail.com> wrote: > On Jul 27, 6:25=A0am, Rhydian <n...@rblack01.plus.com> wrote: > > > [Also posted to comp.lang.vhdl by mistake, sorry about that] > > > Hi, > > > I'm trying to debug a Cyclone design which writes values taken from a > > lookup table to the address inputs of a crosspoint analog switch. =A0Th= e > > problem is that everything looks OK in the Quartus simulator, but when > > I test the design on the target hardware it seems to be pulling the > > wrong values out of the LUT. =A0I have tried enabling SignalTap and > > probing the output pins during the write operation, SignalTap reports > > correct operation but the outputs, as measured on a real logic > > analyser, are wrong. > > > E.g. for CHANNEL=3D1, eeprom_en=3D'0', path=3D0 I should get 0,0,0,0,B,= A, > > 3,2, I actually get 0,0,0,0,9,8,3,2 > > > The lookup table is implemented thus: > > > library ieee; > > use ieee.std_logic_1164.all; > > use ieee.numeric_std.all; > > > entity xpswitch is > > =A0 =A0 =A0 =A0 generic(PLL_CLK_FREQ : integer; > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CHANNEL =A0 =A0 =A0: integer); > > =A0 =A0 =A0 =A0 port( > > =A0 =A0 =A0 =A0 pll_clk =A0 =A0 : in std_logic; > > =A0 =A0 =A0 =A0 sys_rst =A0 =A0 : in std_logic; > > =A0 =A0 =A0 =A0 path_index =A0: in integer range 0 to 7; > > =A0 =A0 =A0 =A0 eeprom_en =A0 : in std_logic; > > =A0 =A0 =A0 =A0 go =A0 =A0 =A0 =A0 =A0: in std_logic; > > =A0 =A0 =A0 =A0 busy =A0 =A0 =A0 =A0: out std_logic; > > =A0 =A0 =A0 =A0 AX =A0 =A0 =A0 =A0 =A0: out std_logic_vector(3 downto 0= ); > > =A0 =A0 =A0 =A0 AY =A0 =A0 =A0 =A0 =A0: out std_logic_vector(2 downto 0= ); > > =A0 =A0 =A0 =A0 CS =A0 =A0 =A0 =A0 =A0: out std_logic; > > =A0 =A0 =A0 =A0 DAT =A0 =A0 =A0 =A0 : buffer std_logic; > > =A0 =A0 =A0 =A0 RST =A0 =A0 =A0 =A0 : out std_logic; > > =A0 =A0 =A0 =A0 STRB =A0 =A0 =A0 =A0: out std_logic > > =A0 =A0 =A0 =A0 ); > > end xpswitch; > > > architecture rtl of xpswitch is > > > =A0 =A0 =A0 =A0 type t_ax_lut is array(0 to 7) of std_logic_vector(3 do= wnto > > 0); > > =A0 =A0 =A0 =A0 signal ax_lut : t_ax_lut; > > =A0 =A0 =A0 =A0 signal ay_count : integer range 0 to 7; > > > begin > > > =A0 =A0 =A0 =A0 p_lut : process(eeprom_en, path_index) begin > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 case CHANNEL is > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when 1 =3D> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if(eepr= om_en =3D '1') then > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 case path_index is > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 when 0 =3D> ax_lut <=3D > > (x"7", x"6", x"8", x"9", x"B", x"A", x"3",x"2"); > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 when 1 =3D> ax_lut <=3D > > (x"7", x"6", x"8", x"9", x"0", x"0", x"0",x"0"); > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 when 2 =3D> ax_lut <=3D > > (x"7", x"6", x"8", x"9", x"4", x"5", x"E",x"F"); > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 when 3 =3D> ax_lut <=3D > > (x"7", x"6", x"8", x"9", x"0", x"0", x"0",x"0"); > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 when 4 =3D> ax_lut <=3D > > (x"7", x"6", x"8", x"9", x"3", x"2", x"B",x"A"); [snip large LUT] > > > There are 3 instances of this code in the design, with different > > switch mappings selected by the CHANNEL parameter. =A0 They all show th= e > > same problem, 'B','A' is consistently replaced by '9','8'. > > > I can't resolve this discrepancy I'm seeing between what the tools are > > telling me and the behaviour when running on the target. =A0The interna= l > > PLL is being used to generate a 57.6 MHz global clock; Quartus timing > > analysis shows f_max as about 85 MHz so i don't think it is a timing > > issue. =A0I have checked the pin assignments by driving the AX outputs > > with a 4-bit counter which cycles continuously, this works correctly > > as seen on the simulator and the external logic analyser. > > > Any ideas? =A0I have raised a support case with Altera, no response as > > yet. > > > TIA > > > R. > > The output will depend on CHANNEL, eeprom_en, path_index but also > ay_count. =A0The first three are inputs, but I don't see where ay_count > is ever assigned a value. =A0Is this signal being set correctly? =A0I > can't explain your symptoms by assuming this signal is not correct, > but it is the only issue I see that might wrong. =A0I also can't explain > your symptoms by assuming any of the inputs are wrong, but fixed. > Could an input be changing as the measurements are made? > > I assume that ay_count free runs through a sequence and the data you > list are the same four signals sampled in time? Yes. > If so, you only have > one output of the four that is wrong. =A0Can you use SignalTap to look > at all the intermediate points and narrow down where it is failing? =A0I > prefer to route the signals out to pins and use the logic analyzer or > scope to look at stuff. =A0I have to use a tool a lot to trust it > (meaning to trust that I am using it right). > > Rick Fixed it now - it turned out that the code was doing exactly what I intended, it was the external IC whose specs I hadn't read properly. Regarding SignalTap, I usually prefer to have a few spare pins routed to test points but this is a very dense board, no space for luxuries like test points! I have always found the Altera JTAG tools to be dependable in the past, anyone have any different experiences?Article: 148534
On Jul 30, 4:47=A0am, Gladys <yuhu...@gmail.com> wrote: > Hi all, > =A0I have to interface DSP with 3 image sensor,s there're only two i2c > GPIO for DSP, so I need to implement an i2c core in FPGA, I've > implemented an i2c slave core to receive data from DSP and store them > with a large =A0LUT in my FPGA and another i2c master core in FPGA to > send the stored i2c data to the 3 sensors, > Now I'm wondering if I can use FPGA as an arbitration core, what the > FPGA does is just to detect the start stop condition and the slave > address, then directly transfer the data to the right sensor without > storing in FPGA itself. > I don't know which method is better, and how to implement the second > method, could anyone give me some suggestion? Thanks There are other options. If you haven't tied down the board design yet you could look at I2C bus switches from NXP and others. These devices allow a single master to access a number of sub-buses to allow multiple parts that consume the same I2C address or larger bus architectures that might create too much load for one I2C segment. Do the sensors all require the same I2C address? if not, you could put more than one on the same bus. Another thing I have done with FPGA's is to implement a pass-through I2C where there is one port for the I2C master and multiple ports to the slaves. The pass-through code flips address bits on the way through so each slave port sees a different address. Then to the master each slave appears at a different location. This way the master doesn't need to do extra operations to switch buses. Your master / slave approach doesn't necessarily require much storage in the FPGA presumably you can just forward each transaction as soon as it is sent. For read operations you can hold off the master using SCL clock-stretching until the operation has been forwarded to the slave. Regards, GaborArticle: 148535
Thank you Gabor, I just found that the FPGA need to store the i2c data and then transfer to the 3 sensor using different i2c bused at the same time, which means the 3 sensors receive the same i2c data, so I still need to implement and i2c slave. As the register address are in 16 bits and not continued, the register data are also in 16bits, is it OK to use an LUT table to store the register data?Article: 148536
On Jul 30, 6:07=A0am, Rhydian <n...@rblack01.plus.com> wrote: > On Jul 28, 5:47=A0pm, rickman <gnu...@gmail.com> wrote: > > > > > On Jul 27, 6:25=A0am, Rhydian <n...@rblack01.plus.com> wrote: > > > > [Also posted to comp.lang.vhdl by mistake, sorry about that] > > > > Hi, > > > > I'm trying to debug a Cyclone design which writes values taken from a > > > lookup table to the address inputs of a crosspoint analog switch. =A0= The > > > problem is that everything looks OK in the Quartus simulator, but whe= n > > > I test the design on the target hardware it seems to be pulling the > > > wrong values out of the LUT. =A0I have tried enabling SignalTap and > > > probing the output pins during the write operation, SignalTap reports > > > correct operation but the outputs, as measured on a real logic > > > analyser, are wrong. > > > > E.g. for CHANNEL=3D1, eeprom_en=3D'0', path=3D0 I should get 0,0,0,0,= B,A, > > > 3,2, I actually get 0,0,0,0,9,8,3,2 > > > > The lookup table is implemented thus: > > > > library ieee; > > > use ieee.std_logic_1164.all; > > > use ieee.numeric_std.all; > > > > entity xpswitch is > > > =A0 =A0 =A0 =A0 generic(PLL_CLK_FREQ : integer; > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CHANNEL =A0 =A0 =A0: integer); > > > =A0 =A0 =A0 =A0 port( > > > =A0 =A0 =A0 =A0 pll_clk =A0 =A0 : in std_logic; > > > =A0 =A0 =A0 =A0 sys_rst =A0 =A0 : in std_logic; > > > =A0 =A0 =A0 =A0 path_index =A0: in integer range 0 to 7; > > > =A0 =A0 =A0 =A0 eeprom_en =A0 : in std_logic; > > > =A0 =A0 =A0 =A0 go =A0 =A0 =A0 =A0 =A0: in std_logic; > > > =A0 =A0 =A0 =A0 busy =A0 =A0 =A0 =A0: out std_logic; > > > =A0 =A0 =A0 =A0 AX =A0 =A0 =A0 =A0 =A0: out std_logic_vector(3 downto= 0); > > > =A0 =A0 =A0 =A0 AY =A0 =A0 =A0 =A0 =A0: out std_logic_vector(2 downto= 0); > > > =A0 =A0 =A0 =A0 CS =A0 =A0 =A0 =A0 =A0: out std_logic; > > > =A0 =A0 =A0 =A0 DAT =A0 =A0 =A0 =A0 : buffer std_logic; > > > =A0 =A0 =A0 =A0 RST =A0 =A0 =A0 =A0 : out std_logic; > > > =A0 =A0 =A0 =A0 STRB =A0 =A0 =A0 =A0: out std_logic > > > =A0 =A0 =A0 =A0 ); > > > end xpswitch; > > > > architecture rtl of xpswitch is > > > > =A0 =A0 =A0 =A0 type t_ax_lut is array(0 to 7) of std_logic_vector(3 = downto > > > 0); > > > =A0 =A0 =A0 =A0 signal ax_lut : t_ax_lut; > > > =A0 =A0 =A0 =A0 signal ay_count : integer range 0 to 7; > > > > begin > > > > =A0 =A0 =A0 =A0 p_lut : process(eeprom_en, path_index) begin > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 case CHANNEL is > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when 1 =3D> > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if(ee= prom_en =3D '1') then > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 case path_index is > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 when 0 =3D> ax_lut <=3D > > > (x"7", x"6", x"8", x"9", x"B", x"A", x"3",x"2"); > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 when 1 =3D> ax_lut <=3D > > > (x"7", x"6", x"8", x"9", x"0", x"0", x"0",x"0"); > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 when 2 =3D> ax_lut <=3D > > > (x"7", x"6", x"8", x"9", x"4", x"5", x"E",x"F"); > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 when 3 =3D> ax_lut <=3D > > > (x"7", x"6", x"8", x"9", x"0", x"0", x"0",x"0"); > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 when 4 =3D> ax_lut <=3D > > > (x"7", x"6", x"8", x"9", x"3", x"2", x"B",x"A"); > > [snip large LUT] > > > > > > > > There are 3 instances of this code in the design, with different > > > switch mappings selected by the CHANNEL parameter. =A0 They all show = the > > > same problem, 'B','A' is consistently replaced by '9','8'. > > > > I can't resolve this discrepancy I'm seeing between what the tools ar= e > > > telling me and the behaviour when running on the target. =A0The inter= nal > > > PLL is being used to generate a 57.6 MHz global clock; Quartus timing > > > analysis shows f_max as about 85 MHz so i don't think it is a timing > > > issue. =A0I have checked the pin assignments by driving the AX output= s > > > with a 4-bit counter which cycles continuously, this works correctly > > > as seen on the simulator and the external logic analyser. > > > > Any ideas? =A0I have raised a support case with Altera, no response a= s > > > yet. > > > > TIA > > > > R. > > > The output will depend on CHANNEL, eeprom_en, path_index but also > > ay_count. =A0The first three are inputs, but I don't see where ay_count > > is ever assigned a value. =A0Is this signal being set correctly? =A0I > > can't explain your symptoms by assuming this signal is not correct, > > but it is the only issue I see that might wrong. =A0I also can't explai= n > > your symptoms by assuming any of the inputs are wrong, but fixed. > > Could an input be changing as the measurements are made? > > > I assume that ay_count free runs through a sequence and the data you > > list are the same four signals sampled in time? > > Yes. > > > If so, you only have > > one output of the four that is wrong. =A0Can you use SignalTap to look > > at all the intermediate points and narrow down where it is failing? =A0= I > > prefer to route the signals out to pins and use the logic analyzer or > > scope to look at stuff. =A0I have to use a tool a lot to trust it > > (meaning to trust that I am using it right). > > > Rick > > Fixed it now - it turned out that the code was doing exactly what I > intended, it was the external IC whose specs I hadn't read properly. > > Regarding SignalTap, I usually prefer to have a few spare pins routed > to test points but this is a very dense board, no space for luxuries > like test points! =A0I have always found the Altera JTAG tools to be > dependable in the past, anyone have any different experiences? Was the other chip driving the signal low? RickArticle: 148537
On Jul 29, 6:43=A0am, Kolja Sulimma <ksuli...@googlemail.com> wrote: > On 29 Jul., 02:34, KJ <kkjenni...@sbcglobal.net> wrote: > > > Instead of this: > > =A0 =A0 Some_slv_sig <=3D std_logic_vector(Some_unsigned); > > Do this > > =A0 =A0 Some_slv_sig <=3D std_ulogic_vector(Some_unsigned); > > a package numeric_unresolved would be nice.... > > Kolja There is no reason why unresolved can't be added to numeric_std is there?Article: 148538
Rune Allnor <allnor@tele.ntnu.no> wrote: >On 30 Jul, 01:42, Tim Wescott <t...@seemywebsite.com> wrote: >> On 07/29/2010 12:47 PM, Steve Pope wrote: >> > You can do this, or you can use a lattice topology >> I did a quick search on "digital lattice filter" and didn't come up with >> any really coherent discussion. There was lots of stuff about how to >> use this or that lattice filter in this or that specialized application, >> but not "this is DF1, this is DF2, this is a digital lattice filter...". >> Got any references? >These filters are treated in medium / advanced level >DSP books, like Proakis & Manolakis. Don't think the >term 'lattice filter' is too common, though; rather >'lattice structure' or 'lattice ladder structure'. >I am not sure they are worth a general discussion: >The problem is that the lattice structure fuses both >the FIR and its IIR inverse, so if the FIR has zeros on >or outside the unit circle, the computations blow up. I do not think this is a problem in practice. The FIR form of any topology is stable; the IIR form of the lattice topology is unconditionally stable if the coefficients are in the range (-1,1) and you are using saturating arithmetic. This latter fact makes them very useful in implementation, because (almost) any IIR filter you would want to implement satisfies this constraint. >It makes a lot of sense keeping those disussion on a >need to know basis. Just FYI, the lattice topology is my first-line choice for implementing a typical IIR such as the OP's Butterworth. I only go to something else if the lattice topology it too costly (it does take 3*N+1 multiplies to implement a N-pole, N-zero filter. But often the multipliers are somewhat lower precision than in other topologies; the coefficients tend to be pretty insensitive.) I have used these filters many, many times because the design time is really short because you don't have to angst over whether you've chosen a well-behaved structure. SteveArticle: 148539
Rune Allnor <allnor@tele.ntnu.no> wrote: >These filters are treated in medium / advanced level >DSP books, like Proakis & Manolakis. Don't think the >term 'lattice filter' is too common, though; rather >'lattice structure' or 'lattice ladder structure'. Also, I'm pretty sure the "wave filters" or "wave lattice filters" are not closely related to (what I am calling) a lattice filter or lattice structure. "lattice-ladder" specifically refers to the topology of this family that gives you both poles and zeros. SteveArticle: 148540
On Jul 30, 12:20=A0pm, rickman <gnu...@gmail.com> wrote: > On Jul 29, 6:43=A0am, Kolja Sulimma <ksuli...@googlemail.com> wrote: > > > On 29 Jul., 02:34, KJ <kkjenni...@sbcglobal.net> wrote: > > > > Instead of this: > > > =A0 =A0 Some_slv_sig <=3D std_logic_vector(Some_unsigned); > > > Do this > > > =A0 =A0 Some_slv_sig <=3D std_ulogic_vector(Some_unsigned); > > > a package numeric_unresolved would be nice.... > > > Kolja > > There is no reason why unresolved can't be added to numeric_std is > there? I don't think you could really *add* the unresolved types to numeric_std because to do so you would have to create new types other than 'unsigned' and 'signed' that are based on std_ulogic. Then of course you would have to get all of the synthesis and simulation vendors on board with the change before you could really use the new types. In the mean time, the 'least common denominator' rule will apply and everyone would continue to use the more supported current data types that are based on the resolved std_logic type...which would then kill all momentum for any of the vendors to support the change and the proposal would likely die quietly. If instead, numeric_std was simply changed from this... type UNSIGNED is array (NATURAL range <>) of STD_LOGIC; type SIGNED is array (NATURAL range <>) of STD_LOGIC; to this... type UNSIGNED is array (NATURAL range <>) of STD_ULOGIC; type SIGNED is array (NATURAL range <>) of STD_ULOGIC; Then the only ones the user community would have to beat on to get this implemented would be the simulation vendors. Synthesis vendors already flag multiple driver violations as a standard part of synthesis since they (for the most part) do not implement multiple net drivers. Changes to standard packages should of course not be taken lightly, but off the top of my head, I can't think of anyone that would be negatively impacted by this. I'll toss this out to the newsgroupies first to see if someone can come up with a use case where the change in the definition of 'unsigned' and 'signed' would negatively impact something. If not, then I'll submit it to the standards group for consideration...numeric_std was so close, they were only two letters short in the source code. Sooooo close. Kevin JenningsArticle: 148541
On 30 Jul, 18:31, spop...@speedymail.org (Steve Pope) wrote: > Rune Allnor =A0<all...@tele.ntnu.no> wrote: > > > > > > >On 30 Jul, 01:42, Tim Wescott <t...@seemywebsite.com> wrote: > >> On 07/29/2010 12:47 PM, Steve Pope wrote: > >> > You can do this, or you can use a lattice topology > >> I did a quick search on "digital lattice filter" and didn't come up wi= th > >> any really coherent discussion. =A0There was lots of stuff about how t= o > >> use this or that lattice filter in this or that specialized applicatio= n, > >> but not "this is DF1, this is DF2, this is a digital lattice filter...= ". > >> Got any references? > >These filters are treated in medium / advanced level > >DSP books, like Proakis & Manolakis. Don't think the > >term 'lattice filter' is too common, though; rather > >'lattice structure' or 'lattice ladder structure'. > >I am not sure they are worth a general discussion: > >The problem is that the lattice structure fuses both > >the FIR and its IIR inverse, so if the FIR has zeros on > >or outside the unit circle, the computations blow up. > > I do not think this is a problem in practice. =A0The FIR > form of any topology is stable; the IIR form of the lattice > topology is unconditionally stable if the coefficients are > in the range (-1,1) My library is unavailable for the moment, so I can't look it up, but as I remember it this constraint is equivalent to the zeros of the FIR being inside the unit circle. The lattice factors are equivalent to the reflection coefficients that pop out from the Levinson recursion, right? > and you are using saturating arithmetic. > This latter fact makes them very useful in implementation, > because (almost) any IIR filter you would want to implement > satisfies this constraint. Would *want* to implement? If I am right about the zeros, that would require a competent designer / user of the filter. Would you risk a design of yours, on some of your students or clients making that call...? RuneArticle: 148542
Rune Allnor <allnor@tele.ntnu.no> wrote: >On 30 Jul, 18:31, spop...@speedymail.org (Steve Pope) wrote: >> I do not think this is a problem in practice. The FIR >> form of any topology is stable; the IIR form of the lattice >> topology is unconditionally stable if the coefficients are >> in the range (-1,1) >My library is unavailable for the moment, so I can't look it >up, but as I remember it this constraint is equivalent to >the zeros of the FIR being inside the unit circle. The lattice >factors are equivalent to the reflection coefficients that pop >out from the Levinson recursion, right? Yes, they are. >> and you are using saturating arithmetic. >> This latter fact makes them very useful in implementation, >> because (almost) any IIR filter you would want to implement >> satisfies this constraint. >Would *want* to implement? If I am right about the zeros, >that would require a competent designer / user of the filter. >Would you risk a design of yours, on some of your students >or clients making that call...? I think you're referring to the filter being user-programmable. If the range of the coefficients is limited to (-1,1), then it is stable. It's pretty straightforward to build this range limit into an implementation. This may not keep the user from programming a useless transfer function into the filter, but it will keep them from creating an unstable filter that oscillates. (You may be addressing some other aspect of the situation, but if so, I'm not picking up on what you're saying.) SteveArticle: 148543
On 31 Jul, 10:05, spop...@speedymail.org (Steve Pope) wrote: > Rune Allnor =A0<all...@tele.ntnu.no> wrote: > > >On 30 Jul, 18:31, spop...@speedymail.org (Steve Pope) wrote: > >> I do not think this is a problem in practice. =A0The FIR > >> form of any topology is stable; the IIR form of the lattice > >> topology is unconditionally stable if the coefficients are > >> in the range (-1,1) > >My library is unavailable for the moment, so I can't look it > >up, but as I remember it this constraint is equivalent to > >the zeros of the FIR being inside the unit circle. The lattice > >factors are equivalent to the reflection coefficients that pop > >out from the Levinson recursion, right? > > Yes, they are. > > >> and you are using saturating arithmetic. > >> This latter fact makes them very useful in implementation, > >> because (almost) any IIR filter you would want to implement > >> satisfies this constraint. > >Would *want* to implement? If I am right about the zeros, > >that would require a competent designer / user of the filter. > >Would you risk a design of yours, on some of your students > >or clients making that call...? > > I think you're referring to the filter being user-programmable. > If the range of the coefficients is limited to (-1,1), then > it is stable. =A0It's pretty straightforward to build this range > limit into an implementation. =A0This may not keep the user > from programming a useless transfer function into the filter, > but it will keep them from creating an unstable filter > that oscillates. > > (You may be addressing some other aspect of the situation, but > if so, I'm not picking up on what you're saying.) I'm referring to what I interpret to be the constraint of FIR zeros to stay inside the unit circle. Being able to use such a filter requires an amount of knowledge and competence on behalf of the user that I would not rely on. The xonstraint only changes the questionfrom "Why is my lattice structure linear phase FIR numerically unstable?" to "Why can't I implement the linear phase FIR as a lattice structure?" OK, you as system designer might have prevented your client from cooking up a disaster, but you are still left with a wining client. RuneArticle: 148544
It would break existing code that used signed/unsigned like SLV, and needed the tri-state, multi-driver logic. Also, elements of unsigned would not be SL, with the same problem. Am I just dreaming, or wasn't there an effort to change the relationship between SLV and SULV such that they would become interchangeable subtypes like SUL and SL are? E.G. subtype SLV is resolved(SULV); or similar, with a new version of resolved() to match. It seems like the gotcha was that an element of such an SLV would no longer be SL, but SUL. But I thought they got around that. AndyArticle: 148545
Rune Allnor <allnor@tele.ntnu.no> wrote: [Lattice filter topology] >I'm referring to what I interpret to be the constraint of FIR >zeros to stay inside the unit circle. Being able to use such >a filter requires an amount of knowledge and competence on >behalf of the user that I would not rely on. The xonstraint >only changes the questionfrom "Why is my lattice structure >linear phase FIR numerically unstable?" to "Why can't I >implement the linear phase FIR as a lattice structure?" >OK, you as system designer might have prevented your client >from cooking up a disaster, but you are still left with a >wining client. I must say that I'm just not getting your point here. Firstly, the FIR part of such a filter is not unstable. The IIR part cannot be unstable if the coefficients are constrained within the range (-1,1), a constraint that is easily imposed by the implementation whether it be in RTL, or gates, or software/firmware. Other topologies have similar regions of instabilities for their coefficient; but they are not stated as simply. You seem to be fishing for problems specific to the lattice topology that, so far as I know, just aren't there. This is useful, normal, mundane, everday filter topology. SteveArticle: 148546
On 31 Jul, 21:03, spop...@speedymail.org (Steve Pope) wrote: > Rune Allnor =A0<all...@tele.ntnu.no> wrote: > > [Lattice filter topology] > > >I'm referring to what I interpret to be the constraint of FIR > >zeros to stay inside the unit circle. Being able to use such > >a filter requires an amount of knowledge and competence on > >behalf of the user that I would not rely on. The xonstraint > >only changes the questionfrom "Why is my lattice structure > >linear phase FIR numerically unstable?" to "Why can't I > >implement the linear phase FIR as a lattice structure?" > >OK, you as system designer might have prevented your client > >from cooking up a disaster, but you are still left with a > >wining client. > > I must say that I'm just not getting your point here. > > Firstly, the FIR part of such a filter is not unstable. > > The IIR part cannot be unstable if the coefficients are > constrained within the range (-1,1), a constraint that is > easily imposed by the implementation whether it be in RTL, > or gates, or software/firmware. Sure. You know that. I know that. But is that konwledge wide-spread? Would you trust users to depend on knowing these things? > Other topologies have similar regions of instabilities for > their coefficient; but they are not stated as simply. Wrong. The IIRs are stable subject to poles staying strictly inside the unit circle. Zeros might be everywhere, no restrictions there. FIRs are unconditionally stable, at the outset. The lattice structure represents a dobule obfuscation in that it 1) Places restrictions on FIR filter stability 2) Depends on zero locations Ano one of those restrictions would mess up the amateur's mind; the two together would play havoc with anyone in two seconds flat. Remember, the days when people actually read up on DSP before attempting to use the techniques are long since gone. You have to deal with the "Matlab does all the thinking" (TM) generation. > You seem to be fishing for problems specific to the lattice topology > that, so far as I know, just aren't there. =A0This is useful, > normal, mundane, everday filter topology. Again, I don't have my books easily available, so with the caveat that I'm writing off years-old memories: The FIR and IIR parts are tightly coupled in the lattice structure. In effect the N'th order lattice filter does the computations in N stages, with cross-copleing between each stage: The output after *both* n'th stage filters are fed (with different scaling) as input to *both* the n+1'th stages in the lattice. As there are the same number of stages as there are poles (IIR) / zeros (FIR), the IIR part will be unconditionally unstable if there are two zeros on or outside the unit circle. Concequently, the FIR will be unstable, as input from one M order unstable IIR will be used as input to the FIR computations somewhere in the lattice. The only way I can see where one might get away ith this, is if there is exactky one unstable zero of the IIR (reflection coefficient >=3D1) and that the corresponding lattice section is the very last, where its output is not used as input to the FIR. If you think I am wrong, you are welcome to provide proofs to show that the lattice structure is unconditionally stable. RuneArticle: 148547
Rune Allnor <allnor@tele.ntnu.no> replies to my post, >> I must say that I'm just not getting your point here. >> Firstly, the FIR part of such a filter is not unstable. >> The IIR part cannot be unstable if the coefficients are >> constrained within the range (-1,1), a constraint that is >> easily imposed by the implementation whether it be in RTL, >> or gates, or software/firmware. >Sure. You know that. I know that. But is that konwledge >wide-spread? Would you trust users to depend on knowing >these things? Yes, it's as widespread as any stability criteria for any other filter topology. >> Other topologies have similar regions of instabilities for >> their coefficient; but they are not stated as simply. >Wrong. The IIRs are stable subject to poles staying >strictly inside the unit circle. Zeros might be everywhere, >no restrictions there. The same is true for a lattice topology, and for any other common topologies. >FIRs are unconditionally stable, at the outset. >The lattice structure represents a dobule obfuscation in that it >1) Places restrictions on FIR filter stability I have NO idea what you are talking about here. >2) Depends on zero locations Again, you've lost me. Your statements 1) and 2) are not true, so far as I know. >Again, I don't have my books easily available, so with the caveat >that >I'm writing off years-old memories: >The FIR and IIR parts are tightly coupled in the lattice structure. Please look at the figure on page 11-28 of this document: http://www.busim.ee.boun.edu.tr/~resources/fdq.pdf The zero location are controlled by the coefficients v1, v2.... These coefficients do not make the filter unstable. There is no "obfuscation" much less "double obfuscation". This is a perfectly normal, everyday, widely used filter with better stability behavior than most. SteveArticle: 148548
I have an embedded design based on Spartan 3e and I need to be able to update it. Impact is not an option for lack of Xinlinx cables in the field and also because it has become a behemoth since its first version. :( I have a simple adapter that allowed me to update a CPLD by connecting the PC serial port to the JTAG port and I would like to use it to update the SPI PROM that configures the FPGA. After a (I think) thorough research in the Internet I have learned there is no direct way to the SPI PROM through the JTAG port. I have found this link with a simple IP that could make this bridge. I guess I may program the FPGA with it using a modified version of wxsvf player or similar with the low level part modified to drive the aforementioned cable but I have no idea of what to do afterwards. Any hint or pointers for a software that could be used in this case would help. TIA.Article: 148549
On Jul 31, 8:23=A0pm, Elder Costa <costa.el...@gmail.com> wrote: > I have an embedded design based on Spartan 3e and I need to be able to > update it. Impact is not an option for lack of Xinlinx cables in the > field and also because it has become a behemoth since its first > version. :( I have a simple adapter that allowed me to update a CPLD > by connecting the PC serial port to the JTAG port and I would like to > use it to update the SPI PROM that configures the FPGA. > > After a (I think) thorough research in the Internet I have learned > there is no direct way to the SPI PROM through the JTAG port. I have > found this link with a simple IP that could make this bridge. I guess > I may program the FPGA with it using a modified version of wxsvf > player or similar with the low level part modified to drive the > aforementioned cable but I have no idea of what to do afterwards. Any > hint or pointers for a software that could be used in this case would > help. > > TIA. I forgot to add the link: http://forums.xilinx.com/t5/IP-Others/JTAG-BSCAN-to-SPI-gateway-IP-core/m-p= /2753
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