From: "Ken Mac" Newsgroups: comp.arch.fpga Subject: stuck in state in Spartan-II! Date: Thu, 28 Feb 2002 13:28:09 -0000 Organization: Strathclyde University news server Lines: 53 Message-ID: NNTP-Posting-Host: englebert.eee.strath.ac.uk X-Trace: dennis.cc.strath.ac.uk 1014903059 9290 130.159.118.158 (28 Feb 2002 13:30:59 GMT) X-Complaints-To: usenet@dennis.cc.strath.ac.uk NNTP-Posting-Date: Thu, 28 Feb 2002 13:30:59 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!colt.net!newspeer.clara.net!news.clara.net!xara.net!gxn.net!server6.netnews.ja.net!str-ccsun!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:14732 Hello, I am using ISE 4.1 SP3 with a Spartan-II. My VHDL design has 3 processes: Process A: Runs at 33MHz to fill a 16 location FIFO with 8-bit data samples and then keep it full. Process B: Runs at 33MHz to take data from the FIFO when told to and supply it to process C via a register. Process C: Runs at 425kHz and sends FIFO 8-bit data samples to a DAC bit-serially then asks process B for next piece of data. Process A is fed with data via a Visual C++ app (the Spartan-II is mounted on a PCI board) which is synchronised with the FPGA using an interrupt pin that the FPGA can assert and the C++ can read. I have used this system for many designs with no trouble (none of them had multiple clock domains however). The problem here is that the design is getting stuck in state for no apparent reason! (i.e. the C++ hangs waiting for the interrupt pin!). The system works for a random number of samples (between 28 and 33 it seems) and then gets stuck in state. This is very strange because it means that my protocols do work. The weird thing is that I put a piece of debug code in another state to send a signal out to a pin to probe, I ran the flow again to get a bitstream and the system ran perfectly for all 75001 samples I am using! The debug code was "Debug <= '1'". Then I enabled clock DLLs using the BUFGDLL component and it hangs again! Previously, I had it working perfectly using the clock DLLs but without a FIFO (i.e. 1 sample at a time from C++ to FPGA to DAC) but I got some stutters hence I introduced the FIFO. In that design I also had hanging problems but after I rejigged my protocol in my VHDL state machines it worked perfectly. It seems that seemingly random changes of VHDL make or break the system. I guess it must be to do with my 2 different clock rates but that is the way it has to be. I am at a loss - anyone any ideas? Thanks for your time, Ken ###### Message-ID: <3C7E50A3.E033467E@attbi.com.com> From: Phil Hays Organization: "Real email is phil-hays aATt aATTBIi dDOTt cCOMm" X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: stuck in state in Spartan-II! References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 88 NNTP-Posting-Host: 12.230.124.133 X-Complaints-To: abuse@attbi.com X-Trace: rwcrnsc52.ops.asp.att.net 1014910795 12.230.124.133 (Thu, 28 Feb 2002 15:39:55 GMT) NNTP-Posting-Date: Thu, 28 Feb 2002 15:39:55 GMT Date: Thu, 28 Feb 2002 15:39:55 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!news.maxwell.syr.edu!newsfeed.cwix.com!wn2feed!worldnet.att.net!204.127.198.204!attbi_feed4!attbi.com!rwcrnsc52.ops.asp.att.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:14726 Ken Mac wrote: > My VHDL design has 3 processes: > > Process A: Runs at 33MHz to fill a 16 location FIFO with 8-bit data > samples and then keep it full. > Process B: Runs at 33MHz to take data from the FIFO when told to and > supply it to process C via a register. > Process C: Runs at 425kHz and sends FIFO 8-bit data samples to a DAC > bit-serially then asks process B for next piece of data. > Process A is fed with data via a Visual C++ app (the Spartan-II is mounted > on a PCI board) which is synchronised with the FPGA using an interrupt pin > that the FPGA can assert and the C++ can read. > > I have used this system for many designs with no trouble (none of them had > multiple clock domains however). The problem here is that the design is > getting stuck in state for no apparent reason! (i.e. the C++ hangs waiting > for the interrupt pin!). Sounds to me like you have a problem crossing clock domains. > The system works for a random number of samples (between 28 and 33 it seems) > and then gets stuck in state. This is very strange because it means that my > protocols do work. Not strange at all. Suppose we have two registers in one clock domain sampling a signal from the other clock domain. If both get the same value for the next clock, the logic works. If only one gets the value, the logic hangs. > The weird thing is that I put a piece of debug code in another state to send > a signal out to a pin to probe, I ran the flow again to get a bitstream and > the system ran perfectly for all 75001 samples I am using! The debug code > was "Debug <= '1'". Different placement, different routing, different timing, different odds of failure. Might work well at 25C, and fail like above at 28C. > Then I enabled clock DLLs using the BUFGDLL component and it hangs again! Different timing, different odds of failure. > Previously, I had it working perfectly using the clock DLLs but without a > FIFO (i.e. 1 sample at a time from C++ to FPGA to DAC) but I got some > stutters hence I introduced the FIFO. > > In that design I also had hanging problems but after I rejigged my protocol > in my VHDL state machines it worked perfectly. > > It seems that seemingly random changes of VHDL make or break the system. I > guess it must be to do with my 2 different clock rates but that is the way > it has to be. > > I am at a loss - anyone any ideas? First, sync the 425KHz to 33 MHz, then edge detect, and then use the edge detected clock 425 for a clock enable for process C. Code fragments: process(clk33) begin if rising_edge(clk33) then synslow <= clk425; synslow2 <= synslow; synslow3 <= synslow2; en425 <= synslow2 and not synslow3; end if; end process; processc: process(clk33) begin -- was (clk425) if rising_edge(clk33) if en425 = '1' then -- was rising_edge(clk425) .... The reason this (hopefully!) will solve your problem is that almost all logic will be running on a single clock. While there is a chance that synslow will not correctly clock in clk425 on rising or falling edge ("go metastable"), synslow2 is much less likely to fail (As mean time between failures >> age of universe), and en425 even less so. Also, you could synchronize all control signals between the two processes. More complex. -- Phil Hays ###### From: "Ken Mac" Newsgroups: comp.arch.fpga Subject: Re: stuck in state in Spartan-II! Date: Thu, 28 Feb 2002 16:55:00 -0000 Organization: Strathclyde University news server Lines: 10 Message-ID: References: <3C7E50A3.E033467E@attbi.com.com> NNTP-Posting-Host: englebert.eee.strath.ac.uk X-Trace: dennis.cc.strath.ac.uk 1014915470 12583 130.159.118.158 (28 Feb 2002 16:57:50 GMT) X-Complaints-To: usenet@dennis.cc.strath.ac.uk NNTP-Posting-Date: Thu, 28 Feb 2002 16:57:50 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!fr.clara.net!heighliner.fr.clara.net!newsfeed.wirehub.nl!easynet-monga!easynet.net!server5.netnews.ja.net!europa.chester.ac.uk!server6.netnews.ja.net!str-ccsun!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:14733 Thanks very much for the detailed suggestion Phil. I will give it a go and let you know what happens! Ken ###### From: "Phil Connor" Newsgroups: comp.arch.fpga Subject: Re: stuck in state in Spartan-II! Date: Thu, 28 Feb 2002 17:06:57 +0000 (UTC) Organization: Mailgate.ORG Server - http://www.Mailgate.ORG Lines: 13 Message-ID: <907321e3ab295d37251ddc2a3b9cf3c4.58911@mygate.mailgate.org> References: <3C7E50A3.E033467E@attbi.com.com> NNTP-Posting-Host: 193.129.127.145 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: news.mailgate.org 1014915669 2420 193.129.127.145 (Thu Feb 28 18:06:57 2002) X-Complaints-To: abuse@mailgate.org NNTP-Posting-Date: Thu, 28 Feb 2002 17:06:57 +0000 (UTC) Injector-Info: news.mailgate.org; posting-host=193.129.127.145; posting-account=58911; posting-date=1014915669 User-Agent: Mailgate Web Server X-URL: http://mygate.mailgate.org/mynews/comp/comp.arch.fpga/907321e3ab295d37251ddc2a3b9cf3c4.58911%40mygate.mailgate.org Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!mygate.mailgate.org!193.129.127.145!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:14728 "Phil Hays" wrote in message news:3C7E50A3.E033467E@attbi.com.com... Elegant solution Phil, well done! Regards Phil C -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG ###### From: "Ken Mac" Newsgroups: comp.arch.fpga Subject: Re: stuck in state in Spartan-II! Date: Fri, 1 Mar 2002 11:23:39 -0000 Organization: Strathclyde University news server Lines: 15 Message-ID: References: <3C7E50A3.E033467E@attbi.com.com> NNTP-Posting-Host: englebert.eee.strath.ac.uk X-Trace: dennis.cc.strath.ac.uk 1014981988 26212 130.159.118.158 (1 Mar 2002 11:26:28 GMT) X-Complaints-To: usenet@dennis.cc.strath.ac.uk NNTP-Posting-Date: Fri, 1 Mar 2002 11:26:28 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!diablo.netcom.net.uk!netcom.net.uk!xara.net!gxn.net!server6.netnews.ja.net!str-ccsun!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:14798 Phil, Your solution did indeed solve the hanging problem - thanks very much for the code! The design now runs for 28 seconds instead of 3 for some other reason but I am sure I can track this down now I can make changes to my VHDL without random state hangs happening! Thanks again, Ken ###### From: "Ken Mac" Newsgroups: comp.arch.fpga Subject: Re: stuck in state in Spartan-II! Date: Fri, 1 Mar 2002 12:23:18 -0000 Organization: Strathclyde University news server Lines: 127 Message-ID: References: <3C7E50A3.E033467E@attbi.com.com> NNTP-Posting-Host: englebert.eee.strath.ac.uk X-Trace: dennis.cc.strath.ac.uk 1014985566 27231 130.159.118.158 (1 Mar 2002 12:26:06 GMT) X-Complaints-To: usenet@dennis.cc.strath.ac.uk NNTP-Posting-Date: Fri, 1 Mar 2002 12:26:06 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!newspeer.clara.net!news.clara.net!btnet-peer!btnet!xara.net!gxn.net!server6.netnews.ja.net!str-ccsun!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:14800 Phil, Forgot to mention that the DAC is fed the 425kHz clock via a pin of my Spartan-II. The DAC uses the negative edges of the 425kHz clock to take data from process C. Process C uses the positive edges of the 425kHz clock to place data on the serial data pin for the DAC and the negative edges then drive the DAC. My DAC output now seems to be irregular - what signal should I use to clock my DAC now? Thanks again, Ken > > Process A: Runs at 33MHz to fill a 16 location FIFO with 8-bit data > > samples and then keep it full. > > Process B: Runs at 33MHz to take data from the FIFO when told to and > > supply it to process C via a register. > > Process C: Runs at 425kHz and sends FIFO 8-bit data samples to a DAC > > bit-serially then asks process B for next piece of data. > > > Process A is fed with data via a Visual C++ app (the Spartan-II is mounted > > on a PCI board) which is synchronised with the FPGA using an interrupt pin > > that the FPGA can assert and the C++ can read. > > > > I have used this system for many designs with no trouble (none of them had > > multiple clock domains however). The problem here is that the design is > > getting stuck in state for no apparent reason! (i.e. the C++ hangs waiting > > for the interrupt pin!). > > Sounds to me like you have a problem crossing clock domains. > > > > The system works for a random number of samples (between 28 and 33 it seems) > > and then gets stuck in state. This is very strange because it means that my > > protocols do work. > > Not strange at all. Suppose we have two registers in one clock domain sampling > a signal from the other clock domain. If both get the same value for the next > clock, the logic works. If only one gets the value, the logic hangs. > > > > The weird thing is that I put a piece of debug code in another state to send > > a signal out to a pin to probe, I ran the flow again to get a bitstream and > > the system ran perfectly for all 75001 samples I am using! The debug code > > was "Debug <= '1'". > > Different placement, different routing, different timing, different odds of > failure. Might work well at 25C, and fail like above at 28C. > > > Then I enabled clock DLLs using the BUFGDLL component and it hangs again! > > Different timing, different odds of failure. > > > > Previously, I had it working perfectly using the clock DLLs but without a > > FIFO (i.e. 1 sample at a time from C++ to FPGA to DAC) but I got some > > stutters hence I introduced the FIFO. > > > > In that design I also had hanging problems but after I rejigged my protocol > > in my VHDL state machines it worked perfectly. > > > > It seems that seemingly random changes of VHDL make or break the system. I > > guess it must be to do with my 2 different clock rates but that is the way > > it has to be. > > > > I am at a loss - anyone any ideas? > > First, sync the 425KHz to 33 MHz, then edge detect, and then use the edge > detected clock 425 for a clock enable for process C. Code fragments: > > process(clk33) begin > if rising_edge(clk33) then > synslow <= clk425; > synslow2 <= synslow; > synslow3 <= synslow2; > en425 <= synslow2 and not synslow3; > end if; > end process; > > processc: > process(clk33) begin -- was (clk425) > if rising_edge(clk33) > if en425 = '1' then -- was rising_edge(clk425) > .... > > The reason this (hopefully!) will solve your problem is that almost all logic > will be running on a single clock. While there is a chance that synslow will > not correctly clock in clk425 on rising or falling edge ("go metastable"), > synslow2 is much less likely to fail (As mean time between failures >> age of > universe), and en425 even less so. > > Also, you could synchronize all control signals between the two processes. More > complex. > > > -- > Phil Hays ###### From: sanket@insight.memec.co.in (Xilinx FAE from Insight SANKET) Newsgroups: comp.arch.fpga Subject: Re: stuck in state in Spartan-II! Date: 1 Mar 2002 06:32:52 -0800 Organization: http://groups.google.com/ Lines: 24 Message-ID: <84bd8d50.0203010632.4a8cad7e@posting.google.com> References: <3C7E50A3.E033467E@attbi.com.com> NNTP-Posting-Host: 203.197.228.208 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1014993172 11466 127.0.0.1 (1 Mar 2002 14:32:52 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 1 Mar 2002 14:32:52 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newscore.univie.ac.at!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feeder.qis.net!sn-xit-02!supernews.com!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:14821 Hi Ken, Are you using any PLLs outside? If yes, then if you do an environment testing with the "Phil" modified code, you may see that for a particular temperature your design works perfectly. Use a DLL in the FPGA instead.This is just a solution on hunch. Have a good day. SANKET. "Ken Mac" wrote in message news:... > Phil, > > Your solution did indeed solve the hanging problem - thanks very much for > the code! > > The design now runs for 28 seconds instead of 3 for some other reason but I > am sure I can track this down now I can make changes to my VHDL without > random state hangs happening! > > Thanks again, > > Ken ###### From: "Ken Mac" Newsgroups: comp.arch.fpga Subject: Re: stuck in state in Spartan-II! Date: Fri, 1 Mar 2002 14:50:30 -0000 Organization: Strathclyde University news server Lines: 37 Message-ID: References: <3C7E50A3.E033467E@attbi.com.com> <84bd8d50.0203010632.4a8cad7e@posting.google.com> NNTP-Posting-Host: englebert.eee.strath.ac.uk X-Trace: dennis.cc.strath.ac.uk 1014994399 29491 130.159.118.158 (1 Mar 2002 14:53:19 GMT) X-Complaints-To: usenet@dennis.cc.strath.ac.uk NNTP-Posting-Date: Fri, 1 Mar 2002 14:53:19 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.wirehub.nl!newsfeed.esat.net!news.heanet.ie!server6.netnews.ja.net!str-ccsun!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:14799 I am not using a PLL outside (I don't think - would the DAC have one?). At the moment my clock configuration is as follows: clk33 comes in on a pin and is fed through a DLL to the design. clk425 also comes in on a pin and is fed through a DLL to the design. I then use Phil's code to create the en425 signal which I use to enable my process C which needs to run at 425kHz to feed the DAC. Do you mean use a DLL on the FPGA to route my DAC clock out? The DAC did work perfectly before when I got my design to work without doing Phils clock synchronisation. I just fed the clk425 out to the DAC on the correct pin. Now I am just not sure how to clock my DAC - do I feed en425 into a DLL and then out to the DAC? Thanks for your help, Ken. > Hi Ken, > > Are you using any PLLs outside? If yes, then if you do an environment > testing with the "Phil" modified code, you may see that for a > particular temperature your design works perfectly. > > Use a DLL in the FPGA instead.This is just a solution on hunch. > Have a good day. > SANKET. ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: stuck in state in Spartan-II! Date: Fri, 01 Mar 2002 13:49:46 -0500 Organization: Arius, Inc Lines: 160 Message-ID: <3C7FCD4A.4D253FE2@yahoo.com> References: <3C7E50A3.E033467E@attbi.com.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVbTkwlhHe4RJE0AKYrH6qIZTcE+L6jDIyAsDkc+OJZaLWkjdYFRYWnh X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 1 Mar 2002 18:49:29 GMT X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!fr.usenet-edu.net!usenet-edu.net!proxad.net!wanadoo.fr!opentransit.net!cpk-news-hub1.bbnplanet.com!news.gtei.net!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:14753 I would continue to use the 425 kHz clock to clock the DAC. I would then use the rising edge of this clock to latch the data out to the DAC data pins. I belive the 425enable signal can just tell the 33 MHz Process B to load new data into the previous register. But I actually would have done your processes a little differently. One of the nice things about the memory in a Spartan II is that they are dual ported with independent clocks. Unless you need a control signal (like Empty or Full) passing between the two domains, you could easily move data without the messy metastability issues. Actually, you HAVE to have some controls passing between the two clock domains because there has to be a counter that increments when you put data in and decrements when you take data out. But this is very easy and is essentially like the syncing you did on the 425EN signal. But it would eliminate the Process B logic. The wide difference in clock speeds makes this a much simpler problem. I assume that you are writing blocks of data to the FIFO? If you are responding to each word that is read out to the DAC, then you don't need the FIFO, right? Ken Mac wrote: > > Phil, > > Forgot to mention that the DAC is fed the 425kHz clock via a pin of my > Spartan-II. > > The DAC uses the negative edges of the 425kHz clock to take data from > process C. > > Process C uses the positive edges of the 425kHz clock to place data on the > serial data pin for the DAC and the negative edges then drive the DAC. > > My DAC output now seems to be irregular - what signal should I use to clock > my DAC now? > > Thanks again, > > Ken > > > > Process A: Runs at 33MHz to fill a 16 location FIFO with 8-bit data > > > samples and then keep it full. > > > Process B: Runs at 33MHz to take data from the FIFO when told to and > > > supply it to process C via a register. > > > Process C: Runs at 425kHz and sends FIFO 8-bit data samples to a DAC > > > bit-serially then asks process B for next piece of data. > > > > > Process A is fed with data via a Visual C++ app (the Spartan-II is > mounted > > > on a PCI board) which is synchronised with the FPGA using an interrupt > pin > > > that the FPGA can assert and the C++ can read. > > > > > > I have used this system for many designs with no trouble (none of them > had > > > multiple clock domains however). The problem here is that the design is > > > getting stuck in state for no apparent reason! (i.e. the C++ hangs > waiting > > > for the interrupt pin!). > > > > Sounds to me like you have a problem crossing clock domains. > > > > > > > The system works for a random number of samples (between 28 and 33 it > seems) > > > and then gets stuck in state. This is very strange because it means that > my > > > protocols do work. > > > > Not strange at all. Suppose we have two registers in one clock domain > sampling > > a signal from the other clock domain. If both get the same value for the > next > > clock, the logic works. If only one gets the value, the logic hangs. > > > > > > > The weird thing is that I put a piece of debug code in another state to > send > > > a signal out to a pin to probe, I ran the flow again to get a bitstream > and > > > the system ran perfectly for all 75001 samples I am using! The debug > code > > > was "Debug <= '1'". > > > > Different placement, different routing, different timing, different odds > of > > failure. Might work well at 25C, and fail like above at 28C. > > > > > Then I enabled clock DLLs using the BUFGDLL component and it hangs > again! > > > > Different timing, different odds of failure. > > > > > > > Previously, I had it working perfectly using the clock DLLs but without > a > > > FIFO (i.e. 1 sample at a time from C++ to FPGA to DAC) but I got some > > > stutters hence I introduced the FIFO. > > > > > > In that design I also had hanging problems but after I rejigged my > protocol > > > in my VHDL state machines it worked perfectly. > > > > > > It seems that seemingly random changes of VHDL make or break the system. > I > > > guess it must be to do with my 2 different clock rates but that is the > way > > > it has to be. > > > > > > I am at a loss - anyone any ideas? > > > > First, sync the 425KHz to 33 MHz, then edge detect, and then use the edge > > detected clock 425 for a clock enable for process C. Code fragments: > > > > process(clk33) begin > > if rising_edge(clk33) then > > synslow <= clk425; > > synslow2 <= synslow; > > synslow3 <= synslow2; > > en425 <= synslow2 and not synslow3; > > end if; > > end process; > > > > processc: > > process(clk33) begin -- was (clk425) > > if rising_edge(clk33) > > if en425 = '1' then -- was rising_edge(clk425) > > .... > > > > The reason this (hopefully!) will solve your problem is that almost all > logic > > will be running on a single clock. While there is a chance that synslow > will > > not correctly clock in clk425 on rising or falling edge ("go metastable"), > > synslow2 is much less likely to fail (As mean time between failures >> age > of > > universe), and en425 even less so. > > > > Also, you could synchronize all control signals between the two processes. > More > > complex. > > > > > > -- > > Phil Hays -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: stuck in state in Spartan-II! Date: Fri, 01 Mar 2002 15:14:46 -0800 Organization: Xilinx Lines: 383 Message-ID: <3C800B65.8FC965E5@xilinx.com> References: <3C7E50A3.E033467E@attbi.com.com> <3C7FCD4A.4D253FE2@yahoo.com> Reply-To: peter.alfke@xilinx.com NNTP-Posting-Host: peter.xsj.xilinx.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------48BC095289FFAC626EAB9B38" X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!fr.clara.net!heighliner.fr.clara.net!proxad.net!enews.sgi.com!nntp.wetware.com!attdv1!attdv2!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:14758 --------------48BC095289FFAC626EAB9B38 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Here is a simple and robust handshake circuit. http://support.xilinx.com/support/techxclusives/MovingData-techX16.htm Peter Alfke, Xilinx Applications rickman wrote: > I would continue to use the 425 kHz clock to clock the DAC. I would > then use the rising edge of this clock to latch the data out to the DAC > data pins. I belive the 425enable signal can just tell the 33 MHz > Process B to load new data into the previous register. > > But I actually would have done your processes a little differently. One > of the nice things about the memory in a Spartan II is that they are > dual ported with independent clocks. Unless you need a control signal > (like Empty or Full) passing between the two domains, you could easily > move data without the messy metastability issues. > > Actually, you HAVE to have some controls passing between the two clock > domains because there has to be a counter that increments when you put > data in and decrements when you take data out. But this is very easy > and is essentially like the syncing you did on the 425EN signal. But it > would eliminate the Process B logic. The wide difference in clock > speeds makes this a much simpler problem. I assume that you are writing > blocks of data to the FIFO? If you are responding to each word that is > read out to the DAC, then you don't need the FIFO, right? > > Ken Mac wrote: > > > > Phil, > > > > Forgot to mention that the DAC is fed the 425kHz clock via a pin of my > > Spartan-II. > > > > The DAC uses the negative edges of the 425kHz clock to take data from > > process C. > > > > Process C uses the positive edges of the 425kHz clock to place data on the > > serial data pin for the DAC and the negative edges then drive the DAC. > > > > My DAC output now seems to be irregular - what signal should I use to clock > > my DAC now? > > > > Thanks again, > > > > Ken > > > > > > Process A: Runs at 33MHz to fill a 16 location FIFO with 8-bit data > > > > samples and then keep it full. > > > > Process B: Runs at 33MHz to take data from the FIFO when told to and > > > > supply it to process C via a register. > > > > Process C: Runs at 425kHz and sends FIFO 8-bit data samples to a DAC > > > > bit-serially then asks process B for next piece of data. > > > > > > > Process A is fed with data via a Visual C++ app (the Spartan-II is > > mounted > > > > on a PCI board) which is synchronised with the FPGA using an interrupt > > pin > > > > that the FPGA can assert and the C++ can read. > > > > > > > > I have used this system for many designs with no trouble (none of them > > had > > > > multiple clock domains however). The problem here is that the design is > > > > getting stuck in state for no apparent reason! (i.e. the C++ hangs > > waiting > > > > for the interrupt pin!). > > > > > > Sounds to me like you have a problem crossing clock domains. > > > > > > > > > > The system works for a random number of samples (between 28 and 33 it > > seems) > > > > and then gets stuck in state. This is very strange because it means that > > my > > > > protocols do work. > > > > > > Not strange at all. Suppose we have two registers in one clock domain > > sampling > > > a signal from the other clock domain. If both get the same value for the > > next > > > clock, the logic works. If only one gets the value, the logic hangs. > > > > > > > > > > The weird thing is that I put a piece of debug code in another state to > > send > > > > a signal out to a pin to probe, I ran the flow again to get a bitstream > > and > > > > the system ran perfectly for all 75001 samples I am using! The debug > > code > > > > was "Debug <= '1'". > > > > > > Different placement, different routing, different timing, different odds > > of > > > failure. Might work well at 25C, and fail like above at 28C. > > > > > > > Then I enabled clock DLLs using the BUFGDLL component and it hangs > > again! > > > > > > Different timing, different odds of failure. > > > > > > > > > > Previously, I had it working perfectly using the clock DLLs but without > > a > > > > FIFO (i.e. 1 sample at a time from C++ to FPGA to DAC) but I got some > > > > stutters hence I introduced the FIFO. > > > > > > > > In that design I also had hanging problems but after I rejigged my > > protocol > > > > in my VHDL state machines it worked perfectly. > > > > > > > > It seems that seemingly random changes of VHDL make or break the system. > > I > > > > guess it must be to do with my 2 different clock rates but that is the > > way > > > > it has to be. > > > > > > > > I am at a loss - anyone any ideas? > > > > > > First, sync the 425KHz to 33 MHz, then edge detect, and then use the edge > > > detected clock 425 for a clock enable for process C. Code fragments: > > > > > > process(clk33) begin > > > if rising_edge(clk33) then > > > synslow <= clk425; > > > synslow2 <= synslow; > > > synslow3 <= synslow2; > > > en425 <= synslow2 and not synslow3; > > > end if; > > > end process; > > > > > > processc: > > > process(clk33) begin -- was (clk425) > > > if rising_edge(clk33) > > > if en425 = '1' then -- was rising_edge(clk425) > > > .... > > > > > > The reason this (hopefully!) will solve your problem is that almost all > > logic > > > will be running on a single clock. While there is a chance that synslow > > will > > > not correctly clock in clk425 on rising or falling edge ("go metastable"), > > > synslow2 is much less likely to fail (As mean time between failures >> age > > of > > > universe), and en425 even less so. > > > > > > Also, you could synchronize all control signals between the two processes. > > More > > > complex. > > > > > > > > > -- > > > Phil Hays > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAX --------------48BC095289FFAC626EAB9B38 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Here is a simple and robust handshake circuit.
http://support.xilinx.com/support/techxclusives/MovingData-techX16.htm
Peter Alfke, Xilinx Applications

rickman wrote:

I would continue to use the 425 kHz clock to clock the DAC.  I would
then use the rising edge of this clock to latch the data out to the DAC
data pins.  I belive the 425enable signal can just tell the 33 MHz
Process B to load new data into the previous register.

But I actually would have done your processes a little differently.  One
of the nice things about the memory in a Spartan II is that they are
dual ported with independent clocks.  Unless you need a control signal
(like Empty or Full) passing between the two domains, you could easily
move data without the messy metastability issues.

Actually, you HAVE to have some controls passing between the two clock
domains because there has to be a counter that increments when you put
data in and decrements when you take data out.  But this is very easy
and is essentially like the syncing you did on the 425EN signal.  But it
would eliminate the Process B logic.  The wide difference in clock
speeds makes this a much simpler problem.  I assume that you are writing
blocks of data to the FIFO?  If you are responding to each word that is
read out to the DAC, then you don't need the FIFO, right?

Ken Mac wrote:
>
> Phil,
>
> Forgot to mention that the DAC is fed the 425kHz clock via a pin of my
> Spartan-II.
>
> The DAC uses the negative edges of the 425kHz clock to take data from
> process C.
>
> Process C uses the positive edges of the 425kHz clock to place data on the
> serial data pin for the DAC and the negative edges then drive the DAC.
>
> My DAC output now seems to be irregular - what signal should I use to clock
> my DAC now?
>
> Thanks again,
>
> Ken
>
> > > Process A:    Runs at 33MHz to fill a 16 location FIFO with 8-bit data
> > > samples and then keep it full.
> > > Process B:    Runs at 33MHz to take data from the FIFO when told to and
> > > supply it to process C via a register.
> > > Process C:    Runs at 425kHz and sends FIFO 8-bit data samples to a DAC
> > > bit-serially then asks process B for next piece of data.
> >
> > > Process A is fed with data via a Visual C++ app (the Spartan-II is
> mounted
> > > on a PCI board) which is synchronised with the FPGA using an interrupt
> pin
> > > that the FPGA can assert and the C++ can read.
> > >
> > > I have used this system for many designs with no trouble (none of them
> had
> > > multiple clock domains however).  The problem here is that the design is
> > > getting stuck in state for no apparent reason!  (i.e. the C++ hangs
> waiting
> > > for the interrupt pin!).
> >
> > Sounds to me like you have a problem crossing clock domains.
> >
> >
> > > The system works for a random number of samples (between 28 and 33 it
> seems)
> > > and then gets stuck in state. This is very strange because it means that
> my
> > > protocols do work.
> >
> > Not strange at all.  Suppose we have two registers in one clock domain
> sampling
> > a signal from the other clock domain.  If both get the same value for the
> next
> > clock, the logic works.  If only one gets the value, the logic hangs.
> >
> >
> > > The weird thing is that I put a piece of debug code in another state to
> send
> > > a signal out to a pin to probe, I ran the flow again to get a bitstream
> and
> > > the system ran perfectly for all 75001 samples I am using!  The debug
> code
> > > was "Debug <= '1'".
> >
> > Different placement, different routing, different timing, different odds
> of
> > failure.  Might work well at 25C, and fail like above at 28C.
> >
> > > Then I enabled clock DLLs using the BUFGDLL component and it hangs
> again!
> >
> > Different timing, different odds of failure.
> >
> >
> > > Previously, I had it working perfectly using the clock DLLs but without
> a
> > > FIFO (i.e. 1 sample at a time from C++ to FPGA to DAC) but I got some
> > > stutters hence I introduced the FIFO.
> > >
> > > In that design I also had hanging problems but after I rejigged my
> protocol
> > > in my VHDL state machines it worked perfectly.
> > >
> > > It seems that seemingly random changes of VHDL make or break the system.
> I
> > > guess it must be to do with my 2 different clock rates but that is the
> way
> > > it has to be.
> > >
> > > I am at a loss - anyone any ideas?
> >
> > First, sync the 425KHz to 33 MHz, then edge detect, and then use the edge
> > detected clock 425 for a clock enable for process C.  Code fragments:
> >
> > process(clk33) begin
> >   if rising_edge(clk33) then
> >     synslow <= clk425;
> >     synslow2 <= synslow;
> >     synslow3 <= synslow2;
> >     en425 <= synslow2 and not synslow3;
> >   end if;
> > end process;
> >
> > processc:
> > process(clk33) begin -- was (clk425)
> >   if rising_edge(clk33)
> >     if en425 = '1' then -- was rising_edge(clk425)
> >     ....
> >
> > The reason this (hopefully!) will solve your problem is that almost all
> logic
> > will be running on a single clock.  While there is a chance that synslow
> will
> > not correctly clock in clk425 on rising or falling edge ("go metastable"),
> > synslow2 is much less likely to fail (As mean time between failures >> age
> of
> > universe), and en425 even less so.
> >
> > Also, you could synchronize all control signals between the two processes.
> More
> > complex.
> >
> >
> > --
> > Phil Hays

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

--------------48BC095289FFAC626EAB9B38-- ###### Message-ID: <3C8057B0.6A863AE8@attbi.com.com> From: Phil Hays Organization: "Real email is phil-hays aATt aATTBIi dDOTt cCOMm" X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: stuck in state in Spartan-II! References: <3C7E50A3.E033467E@attbi.com.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 26 NNTP-Posting-Host: 12.230.124.133 X-Complaints-To: abuse@attbi.com X-Trace: rwcrnsc53 1015043670 12.230.124.133 (Sat, 02 Mar 2002 04:34:30 GMT) NNTP-Posting-Date: Sat, 02 Mar 2002 04:34:30 GMT Date: Sat, 02 Mar 2002 04:34:30 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.cwix.com!wn2feed!wn4feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!rwcrnsc53.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:14779 Ken Mac wrote: > > Phil, > > Forgot to mention that the DAC is fed the 425kHz clock via a pin of my > Spartan-II. > > The DAC uses the negative edges of the 425kHz clock to take data from > process C. > > Process C uses the positive edges of the 425kHz clock to place data on the > serial data pin for the DAC and the negative edges then drive the DAC. > > My DAC output now seems to be irregular - what signal should I use to clock > my DAC now? I'm not quite sure what you mean by irregular. If you used a version of 425 kHz that had been synchronized to the 33 MHz clock, there would be noticable jitter in the timing of the DAC output. Do you mean jitter in the timing of new data output from the DAC? Hope this helps. -- Phil Hays