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 Wed, 13 May 2015 05:37:17 -0700 (PDT), kkoorndyk <kris.koorndyk@gmail.com> wrote: >On Tuesday, May 12, 2015 at 9:42:58 PM UTC-4, John Larkin wrote: >> On Tue, 12 May 2015 13:57:47 -0700 (PDT), >> lasselangwadtchristensen@gmail.com wrote: >> >> >Den mandag den 11. maj 2015 kl. 19.59.43 UTC+2 skrev John Larkin: >> >> Does anyone know if the ZYNQ chips have an internal high-temperature >> >> shutdown? They are behaving like they do. >> >> >> > >> >looks like you have to enable it (it may be default) and you have to load the PL >> > >> >30.3.6 Critical Over-temperature Alarm >> >Note: This feature sends an interrupt status to the PS and causes an automatic shutdown feature for >> >the PL side of the Zynq-7000 device if enabled. Th e PL shutdown is enabled via the bitstream and the >> >PL will only come out of power-down if th e over-temperature alarm goes inactive or a >> >reconfiguration occurs. >> >The on-chip temperature measurement is used for critical temperature warnings. The default over >> >temperature threshold is 125°C. This threshold is used when the contents of the OT Upper Alarm >> >register (listed in UG480) have not been configured. When the die temperature exceeds the >> >threshold set in the XADC's Control register, the ov er-temperature alarm (OT) becomes active. The OT >> >signal resets when the die temperature has fallen below set threshold. >> >The OT alarm can also be used to automatically power down the PL upon activation. The OT alarm can >> >be disabled by writing a 1 to the OT bit in the XADC's Configuration register. >> >Note: these registers are in the XADC and are accessible using the DRP. >> > >> >-Lasse >> >> It's probably shutting down at 125C, without our specifically >> programming any temperature. >> >> Extensive searching, by us and by Avnet, finds no fan that matches the >> hole spacing on the MicroZed board. So we'll fab a little aluminum >> adapter plate and use a standard fan. With a pin-fin heat sink glued >> to the 7020 FPGA, and the fan blowing down on that, we can run at 100C >> ambient. >> >> >> >> -- >> >> John Larkin Highland Technology, Inc >> picosecond timing laser drivers and controllers >> >> jlarkin att highlandtechnology dott com >> http://www.highlandtechnology.com > >The MicroZed has a -I part on it, right? Those parts are spec'd at a max junction temp of 100 C. You need the Expanded temperature grade parts (Q) to get the 125 C junction temps. It's 99% likely that all the chips come off the same wafer. The faster ones may get binned as the high-temp versions. The real issue is timing margins, and our fastest clock is only 128 MHz. (We buy two different Altera parts, one with twice the logic cells and RAM and price and stuff. They are actually identical, run the same bitstreams compiled for either part.) Here's the fan, with its adapter plate. The box runs fine at 100C ambient. Next time we recompile the design, in a couple of months maybe, we'll bring out the chip temperature sensor to see how hot it actually is inside there. https://dl.dropboxusercontent.com/u/53724080/Thermal/Uzed_Fan_Top.JPG https://dl.dropboxusercontent.com/u/53724080/Thermal/Uzed_Fan_Side.JPG It's really insane that we should have to do this. I once built and calibrated a ring oscillator to measure FPGA chip temperature. That's another story. -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.comArticle: 157926
Den onsdag den 13. maj 2015 kl. 22.18.29 UTC+2 skrev John Larkin: > On Wed, 13 May 2015 05:37:17 -0700 (PDT), kkoorndyk > <kris.koorndyk@gmail.com> wrote: >=20 > >On Tuesday, May 12, 2015 at 9:42:58 PM UTC-4, John Larkin wrote: > >> On Tue, 12 May 2015 13:57:47 -0700 (PDT), > >> lasselangwadtchristensen@gmail.com wrote: > >>=20 > >> >Den mandag den 11. maj 2015 kl. 19.59.43 UTC+2 skrev John Larkin: > >> >> Does anyone know if the ZYNQ chips have an internal high-temperatur= e > >> >> shutdown? They are behaving like they do. > >> >>=20 > >> > > >> >looks like you have to enable it (it may be default) and you have to = load the PL=20 > >> > > >> >30.3.6 Critical Over-temperature Alarm > >> >Note: This feature sends an interrupt status to the PS and causes an= automatic shutdown feature for=20 > >> >the PL side of the Zynq-7000 device if enabled. Th e PL shutdown is e= nabled via the bitstream and the=20 > >> >PL will only come out of power-down if th e over-temperature alarm go= es inactive or a=20 > >> >reconfiguration occurs. > >> >The on-chip temperature measurement is used for critical temperature = warnings. The default over=20 > >> >temperature threshold is 125=B0C. This threshold is used when the co= ntents of the OT Upper Alarm=20 > >> >register (listed in UG480) have not been configured. When the die tem= perature exceeds the=20 > >> >threshold set in the XADC's Control register, the ov er-temperature a= larm (OT) becomes active. The OT=20 > >> >signal resets when the die temperature has fallen below set threshol= d.=20 > >> >The OT alarm can also be used to automatically power down the PL upon= activation. The OT alarm can=20 > >> >be disabled by writing a 1 to the OT bit in the XADC's Configuratio= n register. > >> >Note: these registers are in the XADC and are accessible using the DR= P. > >> > > >> >-Lasse > >>=20 > >> It's probably shutting down at 125C, without our specifically > >> programming any temperature. > >>=20 > >> Extensive searching, by us and by Avnet, finds no fan that matches the > >> hole spacing on the MicroZed board. So we'll fab a little aluminum > >> adapter plate and use a standard fan. With a pin-fin heat sink glued > >> to the 7020 FPGA, and the fan blowing down on that, we can run at 100C > >> ambient. > >>=20 > >>=20 > >>=20 > >> --=20 > >>=20 > >> John Larkin Highland Technology, Inc > >> picosecond timing laser drivers and controllers > >>=20 > >> jlarkin att highlandtechnology dott com > >> http://www.highlandtechnology.com > > > >The MicroZed has a -I part on it, right? Those parts are spec'd at a ma= x junction temp of 100 C. You need the Expanded temperature grade parts (Q= ) to get the 125 C junction temps. >=20 > It's 99% likely that all the chips come off the same wafer. The faster > ones may get binned as the high-temp versions. >=20 > The real issue is timing margins, and our fastest clock is only 128 > MHz. >=20 > (We buy two different Altera parts, one with twice the logic cells and > RAM and price and stuff. They are actually identical, run the same > bitstreams compiled for either part.) >=20 > Here's the fan, with its adapter plate. The box runs fine at 100C > ambient. Next time we recompile the design, in a couple of months > maybe, we'll bring out the chip temperature sensor to see how hot it > actually is inside there. >=20 if you have a jtag cable you should able to read it out and I think the driver is installed by default in the xilinx linux image some where down in /sys/bus/iio/devices/iio:device0 -LasseArticle: 157927
On Wednesday, May 13, 2015 at 6:37:19 AM UTC-6, kkoorndyk wrote: > The MicroZed has a -I part on it, right? Those parts are spec'd at a max junction temp of 100 C. You need the Expanded temperature grade parts (Q) to get the 125 C junction temps. MicroZed can be purchased off the shelf with either a -C or -I. A -Q is possible through a custom build by contacting customize at avnet dot com BryanArticle: 157928
On Thu, 14 May 2015 09:45:11 -0700 (PDT), bryan.at.avnet@gmail.com wrote: >On Wednesday, May 13, 2015 at 6:37:19 AM UTC-6, kkoorndyk wrote: >> The MicroZed has a -I part on it, right? Those parts are spec'd at a max junction temp of 100 C. You need the Expanded temperature grade parts (Q) to get the 125 C junction temps. > >MicroZed can be purchased off the shelf with either a -C or -I. A -Q is possible through a custom build by contacting customize at avnet dot com > >Bryan We are buying AES-Z7MB-7Z020-SOM-G. I'm not sure which version of the FPGA is on that. Seems fine at 100C ambient, with our fan. I couldn't persuade the engineer to crank the temperature any higher. I like to test things to destruction. Nobody at Avnet wants to discuss the fan-mount hole spacing, or name a fan that fits. -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.comArticle: 157929
> Nobody at Avnet wants to discuss the fan-mount hole spacing, or name a > fan that fits. I don't have the measurements, but it seems like it's a very common cooler among motherboards: http://www.ixbt.com/mainboard/msi/k9n4-sli/cooler.jpg Regards Tomas D.Article: 157930
> I don't have the measurements, but it seems like it's a very common cooler > among motherboards: > http://www.ixbt.com/mainboard/msi/k9n4-sli/cooler.jpg Here it is: http://www.aliexpress.com/item/Northbridge-motherboard-graphics-heatsink-6cm-pitch-40-40MM-ultra-quiet-fan/1714057574.html Maybe fits the size? Regards Tomas D.Article: 157931
Den torsdag den 14. maj 2015 kl. 23.53.37 UTC+2 skrev Tomas D.: > > I don't have the measurements, but it seems like it's a very common cooler > > among motherboards: > > http://www.ixbt.com/mainboard/msi/k9n4-sli/cooler.jpg > > > Here it is: > http://www.aliexpress.com/item/Northbridge-motherboard-graphics-heatsink-6cm-pitch-40-40MM-ultra-quiet-fan/1714057574.html > > Maybe fits the size? > > Regards > Tomas D. not even close the mounting fan holes on the Microzed is 2mm, and the diagonal spacing is ~31.5mm, that is some where between a 25x25mm and 30x30mm fan and the heatsink has to fit in a ~17x17mm footprint because there are caps that are taller than the Zynq right next to it -LasseArticle: 157932
On Thu, 14 May 2015 16:55:06 -0700 (PDT), lasselangwadtchristensen@gmail.com wrote: >Den torsdag den 14. maj 2015 kl. 23.53.37 UTC+2 skrev Tomas D.: >> > I don't have the measurements, but it seems like it's a very common cooler >> > among motherboards: >> > http://www.ixbt.com/mainboard/msi/k9n4-sli/cooler.jpg >> >> >> Here it is: >> http://www.aliexpress.com/item/Northbridge-motherboard-graphics-heatsink-6cm-pitch-40-40MM-ultra-quiet-fan/1714057574.html >> >> Maybe fits the size? >> >> Regards >> Tomas D. > >not even close > >the mounting fan holes on the Microzed is 2mm, and the diagonal spacing >is ~31.5mm, that is some where between a 25x25mm and 30x30mm fan > >and the heatsink has to fit in a ~17x17mm footprint because there are caps >that are taller than the Zynq right next to it The hole spacing may be English units, namely 1.25" I did look at a lot of CPU cooler fans. There are many, many hole spacings, except that one. We'll just order a bucket of those adapter plates and get on with our lives. We're gluing a Cool Innovations pin-fin sink to the top of the FPGA and blowing air down on that. Without the forced air, the pin fins are useless. But the base of the heat sink spreads heat laterally out from the central hot-spot (a flat metal plate works the same) and cuts junction temp by 5C or so. -- John Larkin Highland Technology, Inc picosecond timing laser drivers and controllers jlarkin att highlandtechnology dott com http://www.highlandtechnology.comArticle: 157933
Den fredag den 15. maj 2015 kl. 04.58.36 UTC+2 skrev John Larkin: > On Thu, 14 May 2015 16:55:06 -0700 (PDT), > lasselangwadtchristensen@gmail.com wrote: > > >Den torsdag den 14. maj 2015 kl. 23.53.37 UTC+2 skrev Tomas D.: > >> > I don't have the measurements, but it seems like it's a very common cooler > >> > among motherboards: > >> > http://www.ixbt.com/mainboard/msi/k9n4-sli/cooler.jpg > >> > >> > >> Here it is: > >> http://www.aliexpress.com/item/Northbridge-motherboard-graphics-heatsink-6cm-pitch-40-40MM-ultra-quiet-fan/1714057574.html > >> > >> Maybe fits the size? > >> > >> Regards > >> Tomas D. > > > >not even close > > > >the mounting fan holes on the Microzed is 2mm, and the diagonal spacing > >is ~31.5mm, that is some where between a 25x25mm and 30x30mm fan > > > >and the heatsink has to fit in a ~17x17mm footprint because there are caps > >that are taller than the Zynq right next to it > > The hole spacing may be English units, namely 1.25" yeh, but they aren't normally spec'ed by the diagnal > I did look at a lot of CPU cooler fans. There are many, many hole > spacings, except that one. yeh, a 25x25 fan is 20x20 holes, a 30x30 is 24x24mm the microzed need ~22x22 mm > > We'll just order a bucket of those adapter plates and get on with our > lives. I'd make the plate bigger so it could use the four mounting holes, those 2mm holes are bit small > > We're gluing a Cool Innovations pin-fin sink to the top of the FPGA > and blowing air down on that. > > Without the forced air, the pin fins are useless. But the base of the > heat sink spreads heat laterally out from the central hot-spot (a flat > metal plate works the same) and cuts junction temp by 5C or so. > we have a fan mounted vertically in our box so it blows air across the top and bottom of the PCB, even with out a heatsink I think it drops the temp 20'C -LasseArticle: 157934
> Without the forced air, the pin fins are useless. But the base of the > heat sink spreads heat laterally out from the central hot-spot (a flat > metal plate works the same) and cuts junction temp by 5C or so. It seems like the best solution for you would be your own board. Maybe worth outsourcing that? You know you're overpaying for that board from Avnet, plus that heatsink solution... Not technological I'd say. Tomas D.Article: 157935
Den fredag den 15. maj 2015 kl. 14.38.01 UTC+2 skrev Tomas D.: > > Without the forced air, the pin fins are useless. But the base of the > > heat sink spreads heat laterally out from the central hot-spot (a flat > > metal plate works the same) and cuts junction temp by 5C or so. > > It seems like the best solution for you would be your own board. Maybe worth > outsourcing that? You know you're overpaying for that board from Avnet, plus > that heatsink solution... Not technological I'd say. > > Tomas D. Depends on how many you need The pcb needs blind microvias, 8~10 layers, tracks to DDR RAM need to be matched to a few millimeters. So before you have made the layout and sourced all the components and have the thing build the microzed might seem like a bargain. -LasseArticle: 157936
On Fri, 15 May 2015 13:37:58 +0100, "Tomas D." <mailsoc@gmial.com> wrote: >> Without the forced air, the pin fins are useless. But the base of the >> heat sink spreads heat laterally out from the central hot-spot (a flat >> metal plate works the same) and cuts junction temp by 5C or so. > >It seems like the best solution for you would be your own board. Maybe worth >outsourcing that? You know you're overpaying for that board from Avnet, plus >that heatsink solution... Not technological I'd say. > >Tomas D. > The uZed makes sense for low-volume, complex, relatively high-priced products, 10 to maybe 50 units a year. It has the SOC, flash, SDcard, DRAM, gB Ethernet, USB, power supplies, Linux, all that done and working. The two boxes that we've done used all of that stuff. The real downside is the ghastly Xilinx development software and horrible support. Future simpler products that have volume potential, we'll probably switch over from our current habits (separate NXP ARM and Altera chips) to an Altera SOC, now that they are available. https://dl.dropboxusercontent.com/u/53724080/PCBs/TEM2_FPGA.jpg The two-chip thing works, but it wastes a lot of FPGA balls to provide CPU access, and the FPGA register access is only 16 bits wide, asynchronous and slow. -- John Larkin Highland Technology, Inc picosecond timing laser drivers and controllers jlarkin att highlandtechnology dott com http://www.highlandtechnology.comArticle: 157937
> The uZed makes sense for low-volume, complex, relatively high-priced > products, 10 to maybe 50 units a year. It has the SOC, flash, SDcard, > DRAM, gB Ethernet, USB, power supplies, Linux, all that done and > working. The two boxes that we've done used all of that stuff. The > real downside is the ghastly Xilinx development software and horrible > support. > > Future simpler products that have volume potential, we'll probably > switch over from our current habits (separate NXP ARM and Altera > chips) to an Altera SOC, now that they are available. > > https://dl.dropboxusercontent.com/u/53724080/PCBs/TEM2_FPGA.jpg > > The two-chip thing works, but it wastes a lot of FPGA balls to provide > CPU access, and the FPGA register access is only 16 bits wide, > asynchronous and slow. We use Altera Cyclone V SoC for automotive and so far - it's great. I can't tell about reliability yet, but the support from Altera was amazing. We've got exactly zero from X. Tomas D.Article: 157938
On Fri, 15 May 2015 22:40:44 +0100, "Tomas D." <mailsoc@gmial.com> wrote: >> The uZed makes sense for low-volume, complex, relatively high-priced >> products, 10 to maybe 50 units a year. It has the SOC, flash, SDcard, >> DRAM, gB Ethernet, USB, power supplies, Linux, all that done and >> working. The two boxes that we've done used all of that stuff. The >> real downside is the ghastly Xilinx development software and horrible >> support. >> >> Future simpler products that have volume potential, we'll probably >> switch over from our current habits (separate NXP ARM and Altera >> chips) to an Altera SOC, now that they are available. >> >> https://dl.dropboxusercontent.com/u/53724080/PCBs/TEM2_FPGA.jpg >> >> The two-chip thing works, but it wastes a lot of FPGA balls to provide >> CPU access, and the FPGA register access is only 16 bits wide, >> asynchronous and slow. > >We use Altera Cyclone V SoC for automotive and so far - it's great. I can't >tell about reliability yet, but the support from Altera was amazing. We've >got exactly zero from X. > >Tomas D. > Good news. That's probably our future path. -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.comArticle: 157939
Hello boys, I have got a small problem with my finite state machine which I have written in VHDL recently. I tried to create "intelligent" counter triggered by clock with frequency 2 Hz. This counter is built in one state of FSM and is started by pushing a button on DE2 board. Firstly, whole system is in IDLE state and if I push this button, state is changed to COUNTING and counter begin to be incremented and his current value is shown on LED display. After it reach value of modulo, the state COUNTING is left back to IDLE and the counter is set up to zero. My problem is that the counter doesn´t work correctly - the counting value was too great. So I tried to solve it with this construction: if (clk_tick´event and clk_tick = 1) then.... , there are some errors by synthesis: Error (10822): HDL error at Citac_FSM.vhd(57): couldn't implement registers for assignments on this clock edge Error (10821): HDL error at Citac_FSM.vhd(62): can't infer register for "AUTOMAT:flg" because its behavior does not match any supported register model Please, does somebody have an idea to solve it? And what is it correct way to write clock triggered FSM with two (or more) clock sources? ----------------------------------------------------------------------------------------------------------------------------------------------------- library ieee; use ieee.std_logic_1164.all; use ieee.numeric_std.all; use ieee.std_logic_unsigned.all; -- Entita ENTITY Counter_FSM IS GENERIC ( REGSIZE : integer := 8; -- range of counter MODULO : natural := 50 -- modulo value ); PORT ( CLK : IN STD_LOGIC; -- puls 50 MHz CLK_tick : IN STD_LOGIC; -- puls 2 Hz RESET : IN STD_LOGIC; -- reset READY : OUT STD_LOGIC; -- counter is ready to start START_C : IN STD_LOGIC; -- start of counting DOUT : OUT STD_LOGIC_VECTOR(REGSIZE - 1 downto 0) -- output ); END Counter_FSM; -------------------------------------------------------------------------- -- -- Architecture of FSM -- ARCHITECTURE Behavior OF Counter_FSM is type counterState is (IDLE, COUNTING); -- states of FSM signal currCounterState : counterState; -- current state signal nextCounterState : counterState; -- next state signal cnt : std_logic_vector(REGSIZE - 1 downto 0); -- data register for counter begin -------------------------------------------------------------------------- -- -- State update UPDATE: process(RESET, CLK) begin if (RESET = '0') then currCounterState <= IDLE; elsif (CLK'event and CLK = '1') then currCounterState <= nextCounterState; end if; end process; -------------------------------------------------------------------------- -- -- Combi part COMBI: process (clk_tick, start_c, currCounterState) variable flg : std_logic := '0'; begin if (clk_tick'event and clk_tick = '1') then flg := '1'; end if; case currCounterState is when IDLE => cnt <= (others => '0'); -- counter value = zero READY <= '1'; -- we can start if (start_c = '1') then -- if button is pushed nextCounterState <= COUNTING; -- then go to COUNTING state end if; when COUNTING => READY <= '0'; if (flg = '1') then -- Was there impuls of 2 Hz? cnt <= cnt + 1; -- yes -> incrementing flg := '0'; if (cnt = MODULO) then -- if value of cnt = MODULO cnt <= (others => '0'); -- then cnt = zero nextCounterState <= IDLE; -- and next state is IDLE end if; end if; when others => nextCounterState <= IDLE; end case; -- OUTPUT douT <= cnt; end process; -------------------------------------------------------------------------- end Behavior; ----------------------------------------------------------------------------------- Thank you very much. Mirek P.S.: I am sorry my English is not so good. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 157940
Am Montag, 18. Mai 2015 11:29:37 UTC+2 schrieb electrin: > My problem is that the counter doesn=B4t work correctly - the counting > value was too great. So I tried to solve it with this construction: if > (clk_tick=B4event and clk_tick =3D 1) then.... , there are some errors by > synthesis: > Error (10822): HDL error at Citac_FSM.vhd(57): couldn't implement > registers for assignments on this clock edge >=20 > Error (10821): HDL error at Citac_FSM.vhd(62): can't infer register for > "AUTOMAT:flg" because its behavior does not match any supported register > model You should spend some time trying to figure out what discrete logic you wou= ld need to build your described logic, than figure out which logic you inte= nd to have and how to modify VHDL code to reach this. =20 > Please, does somebody have an idea to solve it? And what is it correct wa= y > to write clock triggered FSM with two (or more) clock sources? Two clock sources in same architecture is something you should avoid unless= you are experienced. Each clock source builds one clock domain, signals co= rssing between different clock domains require proper handling (google for = clock domain crossing if you need more information about this topic) In your case, you should use the fast clock to oversample the slow clock an= d detect rising edge with a few clockcyles delay (of fast clock). if rising_edge(fastclock) then slow_sr <=3D slow_sr(3 downto 1) & slowclock; if slow_sr(3 downto 2) =3D "01" then -- rising edge on slowclock [..] =20 best regards, ThomasArticle: 157941
On Monday, 18 May 2015 21:29:37 UTC+12, electrin wrote: > Hello boys, Hi! >=20 > I have got a small problem with my finite state machine which I have > written in VHDL recently. I tried to create "intelligent" counter > triggered by clock with frequency 2 Hz.=20 > This counter is built in one state of FSM and is started by pushing a > button on DE2 board. >=20 In general, the latching of a flip flop can only be triggered by one edge (= rising/faling) on clock signal, so when using multiple clocks things get tr= icky fast - you can't use one clock to load a value into a register and the= n another edge or clock to load a different value into the same register. You can sometimes use the flip-flop's async set and reset signals, but it i= s a slippery slope.... I think the easiest solution to your problem is rather than looking for an = edge in the signal from the button, sample the signal in using the clock si= gnal that runs the counter. Like this: clocked_proc: process(clk) begin if rising_edge(clk) then ... update the rest of your state ... btn_two_cycles_ago <=3D btn_one_cycle_ago; btn_one_cycle_ago <=3D btn; end if; end process; And then in your combinatorial process: if btn_two_cycles_ago =3D '0' and btn_one_cycle_ago =3D '1' then ... do this only when the button is pushed ... end if; Also, I'm not sure if the switches on the DE_0 board are debounced, but if = the clock is slow enough (and 2Hz is..) this has the advantage of debouncin= g the button signal for you. Oh, and don't be tempted to use "if btn_one_cycle_ago =3D '0' and btn =3D '= 1' then....". If the btn signal changes at just as the clock edge hits (ver= y unlikely at 2Hz!) then different parts of your design might see different= values for 'btn' due to the time it takes for signals to propagate across = your FPGA. A good rule is to always have at least one simple flip-flop betw= een your design's logic and any outside signal with transitions that are no= t synchronized with the external clock. A better rule is to have at least two flip-flops, creating a two or three s= tage synchronizer, but for a button or switch one FFis plenty enough - the = MTBF will be many times the rated life cycle of the switch, and with 2Hz cl= ock extra 1/2 second delay for the extra FF will be quite noticeable. Mike.Article: 157942
Hello! I'm having trouble with 4th order butterworth filter. I'm using two cascade biquads in direct form I because it should be more reliable on fixed point designs, as mine is. My input signal is 16-bit wide and so the output should be. My question is: how wide should the coefficients be in terms of bit? Also I'm not very confident with the bus width between adders and multipliers. Should I consider only the most significant bits? - Fabio --------------------------------------- Posted through http://www.FPGARelated.comArticle: 157943
Hi all ,
I implement qpsk demodulator on National instruments Fpga . Now i
want to Demodulate Oqpsk signal . As the difference between qpsk and
oqpsk is only the delay of one bit period in q channel.
Q1. Can a qpsk demodulator with some changes demodulate oqpsk data ?
Q2. If it works , what changes i should make ?
flow of qpsk demodulater what i made..
1. frequency shifter (input from step 4)
2. Matched filter
3. AGC
4. coarse frequency offset estimator (Rife and broostyn
algorithm).
5. Timing recovery (Gardener)
6. DDPLL
7. symbol demapping
what are the stages to be modified?
Q3. suggest me some papers ?
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 157944VHDL is leads to verbose designs which are slow to write and hard to visualise. AHDL is elegant and specifically deigned fpga type architectures. It is as to 'C' whereas VHDL is like Perl - write once and read never. The vast majority of fpga designs use synchronous logic. Fighting with archaic ideas of processes with endless 'global' signals passing between them is like returning to the dark ages of BASIC before structured programming caught on. Most of us think about the change events and not the hold events in a design. The unassigned state evaluating as false (or 0) is a key the the simplicity of AHDL. This is why AHDL code usually compiles and works first time. A simple missing else clause in VHDL will double the amount of logic you end up with - for no gain.Article: 157945
On Tue, 19 May 2015 10:40:24 -0500, if.raso wrote: > Hello! > I'm having trouble with 4th order butterworth filter. I'm using two > cascade biquads in direct form I because it should be more reliable on > fixed point designs, as mine is. If you mean numerically stable, splitting your IIR filter into 2nd- and 1st-order sections is something you should just do, always, except when you want to demonstrate to someone why not splitting an IIR is a _bad_ idea. > My input signal is 16-bit wide and so the output should be. > My question is: how wide should the coefficients be in terms of bit? It depends on how close the poles and zeros are to z = 1 (strictly, how close they are to the unit circle, i.e. |z| = 1). The closer they get, the more your filter response will vary with varying coefficient values. The best way to do this is to just check directly: calculate your theoretical coefficient values, then truncate the coefficients, then recalculate either the response of the filter or it's pole and zero locations. If what you end up with given your truncated coefficients is suitable -- run with it. > Also I'm not very confident with the bus width between adders and > multipliers. > Should I consider only the most significant bits? I'm not sure what you mean about considering only the most significant bits. You can calculate the sensitivity of the filter to quantization noise at each point where truncation (or rounding) happens, and use that as a guide. An easier rule of thumb is, for both the poles and zeros for each filter, find the distance |1 - a|, and pick the smaller of the two (it'll always be the pole, unless you've got a really odd filter). You need, roughly, enough bits to accurately represent that distance squared, plus your input data width. So if |1 - a| = 1/256 and you've got 16 bits coming in, you need 32 bit data paths. -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 157946
philipnchill@gmail.com wrote: > VHDL is leads to verbose designs which are slow to write and hard to visualise. I used to write structural verilog, but for a recent project, structural VHDL. I do find it wordier, but not all that much harder to read or write. For people who started working on logic in the 7400 TTL days, it should be possible to visualize VHDL in a similar way to TTL gates (especially the MSI, such as counters, encoders, and such). I did some AHDL some years ago, but don't remember much about it now. -- glenArticle: 157947
I think you answered a question from the previous century... ThomasArticle: 157948
On 5/18/2015 5:29 AM, electrin wrote: > Hello boys, > > I have got a small problem with my finite state machine which I have > written in VHDL recently. I tried to create "intelligent" counter > triggered by clock with frequency 2 Hz. > This counter is built in one state of FSM and is started by pushing a > button on DE2 board. > > Firstly, whole system is in IDLE state and if I push this button, state is > changed to COUNTING and counter begin to be incremented and his current > value is shown on LED display. After it reach value of modulo, the state > COUNTING is left back to IDLE and the counter is set up to zero. > > My problem is that the counter doesn´t work correctly - the counting > value was too great. So I tried to solve it with this construction: if > (clk_tick´event and clk_tick = 1) then.... , there are some errors by > synthesis: > Error (10822): HDL error at Citac_FSM.vhd(57): couldn't implement > registers for assignments on this clock edge > > Error (10821): HDL error at Citac_FSM.vhd(62): can't infer register for > "AUTOMAT:flg" because its behavior does not match any supported register > model > > > Please, does somebody have an idea to solve it? And what is it correct way > to write clock triggered FSM with two (or more) clock sources? I'm old school so when I write HDL code, I am actually "Describing Hardware" I picture in my head (the HD of HDL). Your hardware seems to have a split personality with part of it in the clocked portion of a process and part in the non-clocked portion. I expect this is not really what you intended. In fact, I expect your error is simply having a non-clocked portion of the process. I suggest you don't use your current clock edge detect code and return to using rising_edge(clk). http://lmgtfy.com/?q=rising_edge(clk) I also suggest you not use clk_tick as a clock, but rather use it as an enable to the main clock, clk. Then your entire circuit will be synchronous and no need to deal with clock domain crossings. -- RickArticle: 157949
El mi=E9rcoles, 20 de mayo de 2015, 9:01:41 (UTC-3), thomas....@gmail.com e= scribi=F3: > I think you answered a question from the previous century... >=20 > Thomas Previous millenium!!! As for the matter itself, if you are in the world of programming for a long= time, you get a sense of how much it takes to make a code/software transit= ion. Programming/coding really is not what it is portrayed to be, in the se= nse everyone thinks transitions from older things to newer things are smoot= h and better because newer things have compatibility mode and are better wr= itten, this is still not tha case (and it is difficult to say if it ever wi= ll be so). Think about how much you can achieve with C89, newer languages h= ave more capabilities, but don't have the same kind of support, and since i= t is a low level language with enough effort (sometimes TOO much) you can a= chieve the same functionality than high level languages. As for specifically VHDL versus AHDL, AHDL has no SERIOUS advantage over VH= DL, only easier coding, and sometimes ease of coding translate into more er= rors (real errors in the design not compiler errors, nobody cares about tha= t, with enough experience you get over all compiler errors and your design = might still not work). This kind of ease of coding can only be an advantage= to someone that has very little experience (hence not relevant enough for = everyone to make a transition to that language). For me I have also my own opinion between VHDL and Verilog, I find VHDL to = be a far more capable language than Verilog bar a few respects (until now i= n VHDL we would have to pre-declare arrays of SLVs), it only takes more tim= e to get used to (SystemVerilog is coming close to VHDL in some respects th= ough, and in other surpassing it by far, even in VHDL-2008) Cheers, and choose the language that gives less design bugs.
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