Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

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

Custom Search

Messages from 157925

Article: 157925
Subject: Re: ZYNQ temperature
From: John Larkin <jlarkin@highlandtechnology.com>
Date: Wed, 13 May 2015 13:18:23 -0700
Links: << >>  << T >>  << A >>
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.com


Article: 157926
Subject: Re: ZYNQ temperature
From: lasselangwadtchristensen@gmail.com
Date: Wed, 13 May 2015 18:38:15 -0700 (PDT)
Links: << >>  << T >>  << A >>
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

-Lasse


Article: 157927
Subject: Re: ZYNQ temperature
From: bryan.at.avnet@gmail.com
Date: Thu, 14 May 2015 09:45:11 -0700 (PDT)
Links: << >>  << T >>  << A >>
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

Article: 157928
Subject: Re: ZYNQ temperature
From: John Larkin <jlarkin@highlandtechnology.com>
Date: Thu, 14 May 2015 13:16:49 -0700
Links: << >>  << T >>  << A >>
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.com


Article: 157929
Subject: Re: ZYNQ temperature
From: "Tomas D." <mailsoc@gmial.com>
Date: Thu, 14 May 2015 22:48:25 +0100
Links: << >>  << T >>  << A >>

> 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
Subject: Re: ZYNQ temperature
From: "Tomas D." <mailsoc@gmial.com>
Date: Thu, 14 May 2015 22:53:34 +0100
Links: << >>  << T >>  << A >>
> 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
Subject: Re: ZYNQ temperature
From: lasselangwadtchristensen@gmail.com
Date: Thu, 14 May 2015 16:55:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 

-Lasse 



Article: 157932
Subject: Re: ZYNQ temperature
From: John Larkin <jlarkin@highlandtechnology.com>
Date: Thu, 14 May 2015 19:58:31 -0700
Links: << >>  << T >>  << A >>
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.com


Article: 157933
Subject: Re: ZYNQ temperature
From: lasselangwadtchristensen@gmail.com
Date: Fri, 15 May 2015 04:23:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 

-Lasse

Article: 157934
Subject: Re: ZYNQ temperature
From: "Tomas D." <mailsoc@gmial.com>
Date: Fri, 15 May 2015 13:37:58 +0100
Links: << >>  << T >>  << A >>
> 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
Subject: Re: ZYNQ temperature
From: lasselangwadtchristensen@gmail.com
Date: Fri, 15 May 2015 07:27:24 -0700 (PDT)
Links: << >>  << T >>  << A >>
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. 


-Lasse

Article: 157936
Subject: Re: ZYNQ temperature
From: John Larkin <jlarkin@highlandtechnology.com>
Date: Fri, 15 May 2015 09:27:12 -0700
Links: << >>  << T >>  << A >>
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.com


Article: 157937
Subject: Re: ZYNQ temperature
From: "Tomas D." <mailsoc@gmial.com>
Date: Fri, 15 May 2015 22:40:44 +0100
Links: << >>  << T >>  << A >>
> 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
Subject: Re: ZYNQ temperature
From: John Larkin <jlarkin@highlandtechnology.com>
Date: Fri, 15 May 2015 15:47:14 -0700
Links: << >>  << T >>  << A >>
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.com


Article: 157939
Subject: Clock triggered FSM
From: "electrin" <95179@FPGARelated>
Date: Mon, 18 May 2015 04:29:34 -0500
Links: << >>  << T >>  << A >>
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.com

Article: 157940
Subject: Re: Clock triggered FSM
From: Thomas Stanka <usenet_nospam_valid@stanka-web.de>
Date: Mon, 18 May 2015 08:02:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
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,

Thomas

Article: 157941
Subject: Re: Clock triggered FSM
From: Mike Field <mikefield1969@gmail.com>
Date: Tue, 19 May 2015 01:38:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: IIR filter bus width
From: "if.raso" <105368@FPGARelated>
Date: Tue, 19 May 2015 10:40:24 -0500
Links: << >>  << T >>  << A >>
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.com

Article: 157943
Subject: Oqpsk Demod
From: "Eshwar varma" <105327@FPGARelated>
Date: Tue, 19 May 2015 10:42:05 -0500
Links: << >>  << T >>  << A >>
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: 157944
Subject: Re: AHDL VS. VHDL
From: philipnchill@gmail.com
Date: Tue, 19 May 2015 15:24:29 -0700 (PDT)
Links: << >>  << T >>  << A >>
VHDL 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
Subject: Re: IIR filter bus width
From: Tim Wescott <seemywebsite@myfooter.really>
Date: Tue, 19 May 2015 19:01:20 -0500
Links: << >>  << T >>  << A >>
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.com

Article: 157946
Subject: Re: AHDL VS. VHDL
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 20 May 2015 04:04:52 +0000 (UTC)
Links: << >>  << T >>  << A >>
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.

-- glen

Article: 157947
Subject: Re: AHDL VS. VHDL
From: thomas.entner99@gmail.com
Date: Wed, 20 May 2015 05:01:37 -0700 (PDT)
Links: << >>  << T >>  << A >>
I think you answered a question from the previous century...

Thomas

Article: 157948
Subject: Re: Clock triggered FSM
From: rickman <gnuarm@gmail.com>
Date: Wed, 20 May 2015 09:13:49 -0400
Links: << >>  << T >>  << A >>
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.

-- 

Rick

Article: 157949
Subject: Re: AHDL VS. VHDL
From: Leonardo Capossio <capossio.leonardo@gmail.com>
Date: Wed, 20 May 2015 08:19:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

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

Custom Search