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
paragon.john@gmail.com wrote: > > The period constraint is on clk_n's differential counterpart clk_p. > Similar unconstrained paths appear for clk_p, I just happened to pick > one that used clk_n. > > I will try a FROM/TO constraint to remove them. Since you doubt that > going down this path will help me out, do you have any insight on what > may be a better way to diagnose possible timing issues that may result > in a mismatch? I have looked through the warnings that the various > stages of ISE spit and haven't seen any that would lend themselves to > a simulation mismatch. You really have not described what the circuit is like. Are there multiple clocks? Are signals crossing between clock domains? Does it actually work correctly at lower clock rates (you said that "the hardware performance of my design does not appear to match simulation"). Mike described the most common problems, and those match my experience too. For difficult problems, if you have not tried chipscope before, give it a try. It is quite handy (hopefully you have an accessible jtag port). If you don't already have it, you can get a trial license for it and start using it immediately. I will sometimes insert a simple error detection circuit in the FPGA that can generate a trigger for chipscope.Article: 125151
On 16 Okt., 22:05, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Antti wrote: > > On 16 Okt., 20:44, Jim Granville <no.s...@designtools.maps.co.nz> > >>I take it if you drive 20 leds, they would all exhibit this operation ? > >>- and that you did apply a fix, that cured it - and such Fix must be > >>applied in SW, as you said the PCB/HW/FPGA are all OK ? > > >>-jg- Zitierten Text ausblenden - > > >>- Zitierten Text anzeigen - > > > Jim, > > > logic is correct, Vccio ok, no pin cell level strangeness either. > > if I connect the signals that driver led1 and led2 to more LEDs then > > each of them would have similar behaviour as LED1/LED2 depenging what > > signal is driving them. > > You did not reply to where SW Fix was, but I see more information is > given in c.a.e ?! > > Seems like this is not a FPGA 'fault' at all, if code in a > not-before-mentioned AVR can cure it ? > > <paste> Antii : > > I did originally posted to C.A.F. so sorry for copy to .embedded I > > only do repost here as realized later that well, the FPGA is made to > > look like working wrong by an Atmel AVR MCU. And the "problem" is > > small piece of code that executes on ATmega8. In the matter of fact > > its only 1 wrong bit in the Atmel code, by changing one bit in the > > Atmel code the FPGA code would work as it is supposed to work. > > So are we to presume this AVR is providing the stimulus signals, that > route thru the working FPGA, and that some Port/RMW issue in the AVR is > the culprit ? > > -jg- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - Hi Jim yes the PCB has FPGA(Actel) and MCU(AVR) on it, the 1 second blink is generated with the MCU. the "issue" appeared when i was debugging an FPGA internal signal, I connected that signal to IO (LED2) LED2 indicated that my FPGA was not working properly (it was that big code that takes 99% of that FPGA). then i connected 1 second blink generated by the Atmel to LED2. and then i did observe the behaviour as described in the original posting. and yes, when I finally found the issue, i changed 1 bit in the AVR firmware and then LEDs did work as they are supposed to work, that is signal driving LED2 was no longer have influence on LED1. AnttiArticle: 125152
On Oct 16, 4:06 pm, Duane Clark <junkm...@junkmail.com> wrote: > paragon.j...@gmail.com wrote: > > > The period constraint is on clk_n's differential counterpart clk_p. > > Similar unconstrained paths appear for clk_p, I just happened to pick > > one that used clk_n. > > > I will try a FROM/TO constraint to remove them. Since you doubt that > > going down this path will help me out, do you have any insight on what > > may be a better way to diagnose possible timing issues that may result > > in a mismatch? I have looked through the warnings that the various > > stages of ISE spit and haven't seen any that would lend themselves to > > a simulation mismatch. > > You really have not described what the circuit is like. > Are there multiple clocks? > Are signals crossing between clock domains? > Does it actually work correctly at lower clock rates (you said that "the > hardware performance of my design does not appear to match simulation"). > > Mike described the most common problems, and those match my experience > too. For difficult problems, if you have not tried chipscope before, > give it a try. It is quite handy (hopefully you have an accessible jtag > port). If you don't already have it, you can get a trial license for it > and start using it immediately. I will sometimes insert a simple error > detection circuit in the FPGA that can generate a trigger for chipscope. This a digital signal processing application done mainly in System Generator. There is one "main" clock domain where all of the critical processing is done. There are domains synchronous to this clock made using clock enables (in System Generator) and also divided clocks that are output by a DCM (in the VHDL that I wrap the sysgen design). I believe that all of this is constrained and controlled properly. There is a asynchronous second clock domain that is used purely for command and control of the design via setting and reading registers. The signals crossing this domain would not affect the performance of the design. The type of simulation mismatch I am seeing is the "performance" of the algorithm I am implementing. The algorithm works, just not as well as I see when I run simulations. I can't use ChipScope, unfortunately. I can get at some test signals via a logic analyzer, but obviously not with the flexibility and ease of chipscope.Article: 125153
On Oct 16, 12:37 pm, ghel...@lycos.com wrote: > The fork call failing could be from just about anything. Two things > that come to mind are (1) Running on an unsupported OS, or (2) The web- > pack is missing the routine that SOPC is trying to fork to. > That was it! I installed Quartus II on a friend's computer and it was able to generate it fine. Thanks for the help! EricArticle: 125154
paragon.john@gmail.com wrote:
> There is one "main" clock domain where all of the critical processing
> is done. There are domains synchronous to this clock made using clock
> enables (in System Generator) and also divided clocks that are output
> by a DCM (in the VHDL that I wrap the sysgen design). I believe that
> all of this is constrained and controlled properly.
Why not do everything with clock enables
and eliminate the divided clocks and
their constraints?
> There is a asynchronous second clock domain that is used purely for
> command and control of the design via setting and reading registers.
> The signals crossing this domain would not affect the performance of
> the design.
Unless one of the async registers
tries to tell the design
to start, stop, or turn left, sending
the machine into and "impossible" state
that simulation can't see.
> The type of simulation mismatch I am seeing is the
> "performance" of the algorithm I am implementing. The algorithm
> works, just not as well as I see when I run simulations.
If it doesn't match the simulation exactly
something is very wrong.
> I can't use ChipScope, unfortunately. I can get at some test signals
> via a logic analyzer, but obviously not with the flexibility and ease
> of chipscope.
A test point is much better than nothing.
Good luck.
-- Mike Treseler
Article: 125155> and yes, when I finally found the issue, i changed 1 bit in the AVR > firmware and then LEDs did work as they are supposed to work, that is > signal driving LED2 was no longer have influence on LED1. OK, let me try. Is the six-letter word GLITCH by any chance? /MikhailArticle: 125156
Hi, I'm trying to generate in hardware the set of all gold codes derived from two m-sequences. I'm having a hard time finding pointers as to how to change the seed of one LFSR with respect to the other so that the resulting m-sequence remains balanced (zeros and ones) and maximal. I found some references that are supposed to contain a fair discussion on this. However, they'r all textbooks to which I don't have access. So was wondering if anybody in here knows of a place on the web that treats this subject. I'm googling as I speak but still weeding through useless stuff. It'll be nice for a change not having to spend a week or so to figure out "mechanical" things on my own. Regards, MannyArticle: 125157
On 17 Okt., 02:03, "MM" <mb...@yahoo.com> wrote: > > and yes, when I finally found the issue, i changed 1 bit in the AVR > > firmware and then LEDs did work as they are supposed to work, that is > > signal driving LED2 was no longer have influence on LED1. > > OK, let me try. Is the six-letter word GLITCH by any chance? > > /Mikhail NO its not so trivial!Article: 125158
Manny wrote: > I'm trying to generate in hardware the set of all gold codes derived > from two m-sequences. I'm having a hard time finding pointers as to > how to change the seed of one LFSR with respect to the other so that > the resulting m-sequence remains balanced (zeros and ones) and > maximal. http://www.google.com/search?q=dsp+gold+code+lfsr+seedArticle: 125159
On 16 Okt., 15:52, avrba...@hotmail.com wrote: > I have indirectly answered this I think, given proper technology > libraries the behaviour would appear in simulation. > if proper simulation models are used it would appear before synthesis > also. So it does indirectly say that there is vendor dependancy. > and as also said the simulation models may be not accurate enough for > the behaviour to become visible. I can not tell that for all vendors > but for Xilinx as example last time I checked the model accuracy would > not make the behaviour observable in simulations. This sounds like a "problem" on the way you use the IO-Buffer to me. I expect you did nothing like using the wrong IO-Standard (e.g. Lvds instead of TTL) and use an IO-Standard useful to drive a LED. Do you have problems with SSO or Groundbounce? Or is it a problem with the IO-Buffer containing a bit more logic than the vhdl-model, so you have some influence from clamping diode or something like that? (I have no clue if there is a possibility for such a behavior without strong technology dependancy) bye ThomasArticle: 125160
On 17 Okt., 07:18, Thomas Stanka <usenet_nospam_va...@stanka-web.de> wrote: > On 16 Okt., 15:52, avrba...@hotmail.com wrote: > > > I have indirectly answered this I think, given proper technology > > libraries the behaviour would appear in simulation. > > if proper simulation models are used it would appear before synthesis > > also. So it does indirectly say that there is vendor dependancy. > > and as also said the simulation models may be not accurate enough for > > the behaviour to become visible. I can not tell that for all vendors > > but for Xilinx as example last time I checked the model accuracy would > > not make the behaviour observable in simulations. > > This sounds like a "problem" on the way you use the IO-Buffer to me. > I expect you did nothing like using the wrong IO-Standard (e.g. Lvds > instead of TTL) and use an IO-Standard useful to drive a LED. > Do you have problems with SSO or Groundbounce? > > Or is it a problem with the IO-Buffer containing a bit more logic than > the vhdl-model, so you have some influence from clamping diode or > something like that? (I have no clue if there is a possibility for > such a behavior without strong technology dependancy) > > bye Thomas NO NO NO not any problem with IO bufferArticle: 125161
You didn't really drive a '1' at the input but just left the input floating, so that the led output had influence on was was "sampled" by the input buffer (EM or small change in the threshold making it switch). SylvainArticle: 125162
On 17 Okt., 08:15, "Sylvain Munaut <Some...@SomeDomain.com>" <246...@gmail.com> wrote: > You didn't really drive a '1' at the input but just left the input > floating, so that the led output had influence on was was "sampled" by > the input buffer (EM or small change in the threshold making it > switch). > > Sylvain no, the issue is not related to any open or floating inputs or any EMI effects AnttiArticle: 125163
Antti schrieb: > On 16 Okt., 22:05, Jim Granville <no.s...@designtools.maps.co.nz> > wrote: >> Antti wrote: >>> On 16 Okt., 20:44, Jim Granville <no.s...@designtools.maps.co.nz> >>>> I take it if you drive 20 leds, they would all exhibit this operation ? >>>> - and that you did apply a fix, that cured it - and such Fix must be >>>> applied in SW, as you said the PCB/HW/FPGA are all OK ? >>>> -jg- Zitierten Text ausblenden - >>>> - Zitierten Text anzeigen - >>> Jim, >>> logic is correct, Vccio ok, no pin cell level strangeness either. >>> if I connect the signals that driver led1 and led2 to more LEDs then >>> each of them would have similar behaviour as LED1/LED2 depenging what >>> signal is driving them. >> You did not reply to where SW Fix was, but I see more information is >> given in c.a.e ?! >> >> Seems like this is not a FPGA 'fault' at all, if code in a >> not-before-mentioned AVR can cure it ? >> >> <paste> Antii : >> > I did originally posted to C.A.F. so sorry for copy to .embedded I >> > only do repost here as realized later that well, the FPGA is made to >> > look like working wrong by an Atmel AVR MCU. And the "problem" is >> > small piece of code that executes on ATmega8. In the matter of fact >> > its only 1 wrong bit in the Atmel code, by changing one bit in the >> > Atmel code the FPGA code would work as it is supposed to work. >> >> So are we to presume this AVR is providing the stimulus signals, that >> route thru the working FPGA, and that some Port/RMW issue in the AVR is >> the culprit ? >> >> -jg- Zitierten Text ausblenden - >> >> - Zitierten Text anzeigen - > > Hi Jim > > yes the PCB has FPGA(Actel) and MCU(AVR) on it, the 1 second blink is > generated with the MCU. > > the "issue" appeared when i was debugging an FPGA internal signal, I > connected that signal to IO (LED2) > LED2 indicated that my FPGA was not working properly (it was that big > code that takes 99% of that FPGA). > > then i connected 1 second blink generated by the Atmel to LED2. > > and then i did observe the behaviour as described in the original > posting. > > and yes, when I finally found the issue, i changed 1 bit in the AVR > firmware and then LEDs did work as they are supposed to work, that is > signal driving LED2 was no longer have influence on LED1. > > Antti > Hi Antti, so there's an extra MCU involved. Who could guess that from your original posting. And you could solve the issue by changing the code in the MCU. Well now it makes sense that everything with the VHDL and FPGA and even the PCB and power is ok. So let me give a try on a 6 letter word: ENABLE By some chance your 1 sec Signal (or some other signal from the cpu that is synchronous to this one) is continously enabling (and disabling) the big Logic, causing the test signal to blink with the same frequency. EilertArticle: 125164
On 17 Okt., 08:32, backhus <n...@nirgends.xyz> wrote: > Antti schrieb: > > > > > On 16 Okt., 22:05, Jim Granville <no.s...@designtools.maps.co.nz> > > wrote: > >> Antti wrote: > >>> On 16 Okt., 20:44, Jim Granville <no.s...@designtools.maps.co.nz> > >>>> I take it if you drive 20 leds, they would all exhibit this operation ? > >>>> - and that you did apply a fix, that cured it - and such Fix must be > >>>> applied in SW, as you said the PCB/HW/FPGA are all OK ? > >>>> -jg- Zitierten Text ausblenden - > >>>> - Zitierten Text anzeigen - > >>> Jim, > >>> logic is correct, Vccio ok, no pin cell level strangeness either. > >>> if I connect the signals that driver led1 and led2 to more LEDs then > >>> each of them would have similar behaviour as LED1/LED2 depenging what > >>> signal is driving them. > >> You did not reply to where SW Fix was, but I see more information is > >> given in c.a.e ?! > > >> Seems like this is not a FPGA 'fault' at all, if code in a > >> not-before-mentioned AVR can cure it ? > > >> <paste> Antii : > >> > I did originally posted to C.A.F. so sorry for copy to .embedded I > >> > only do repost here as realized later that well, the FPGA is made to > >> > look like working wrong by an Atmel AVR MCU. And the "problem" is > >> > small piece of code that executes on ATmega8. In the matter of fact > >> > its only 1 wrong bit in the Atmel code, by changing one bit in the > >> > Atmel code the FPGA code would work as it is supposed to work. > > >> So are we to presume this AVR is providing the stimulus signals, that > >> route thru the working FPGA, and that some Port/RMW issue in the AVR is > >> the culprit ? > > >> -jg- Zitierten Text ausblenden - > > >> - Zitierten Text anzeigen - > > > Hi Jim > > > yes the PCB has FPGA(Actel) and MCU(AVR) on it, the 1 second blink is > > generated with the MCU. > > > the "issue" appeared when i was debugging an FPGA internal signal, I > > connected that signal to IO (LED2) > > LED2 indicated that my FPGA was not working properly (it was that big > > code that takes 99% of that FPGA). > > > then i connected 1 second blink generated by the Atmel to LED2. > > > and then i did observe the behaviour as described in the original > > posting. > > > and yes, when I finally found the issue, i changed 1 bit in the AVR > > firmware and then LEDs did work as they are supposed to work, that is > > signal driving LED2 was no longer have influence on LED1. > > > Antti > > Hi Antti, > so there's an extra MCU involved. Who could guess that from your > original posting. And you could solve the issue by changing the code in > the MCU. Well now it makes sense that everything with the VHDL and FPGA > and even the PCB and power is ok. > > So let me give a try on a 6 letter word: > ENABLE > > By some chance your 1 sec Signal (or some other signal from the cpu that > is synchronous to this one) is continously enabling (and disabling) the > big Logic, causing the test signal to blink with the same frequency. > > Eilert- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - Hi morning we are getting little closer ENABLE is not the word, but first letter is the same :) the 1 second signal doesnt actually enable or disable the logic in the FPGA the logic remains functional, no matter the signal value the MCU was really generating a "test debug led blink signal" and i expected that signal to work as such, but it had this described side- effect, of controlling another output depending on the out value of that port. Antti From laurent.pinchart@skynet.be Wed Oct 17 00:44:57 2007 Path: newssvr25.news.prodigy.net!newsdbm05.news.prodigy.net!newsdst01.news.prodigy.net!prodigy.com!newscon04.news.prodigy.net!prodigy.net!goblin2!goblin.stu.neva.ru!ecngs!feeder2.ecngs.de!novso.com!news.skynet.be!195.238.0.222.MISMATCH!newsspl501.isp.belgacom.be!tjb!not-for-mail Message-Id: <4715bd79$0$22305$ba620e4c@news.skynet.be> From: Laurent Pinchart <laurent.pinchart@skynet.be> Subject: Re: FPGA quiz: what can be wrong Newsgroups: comp.arch.fpga Date: Wed, 17 Oct 2007 09:44:57 +0200 References: <1192462938.206319.120810@i13g2000prf.googlegroups.com> <5nhppuFhleodU1@mid.individual.net> <1192473204.719381.50050@t8g2000prg.googlegroups.com> <4714292e@clear.net.nz> <1192513559.629757.69460@z24g2000prh.googlegroups.com> <47146238$1@clear.net.nz> <1192521649.640303.274860@q5g2000prf.googlegroups.com> <47147795@clear.net.nz> <47148945$1@clear.net.nz> <1192528320.072706.287440@q5g2000prf.googlegroups.com> <47150635$1@clear.net.nz> <1192561326.944600.56940@k35g2000prh.googlegroups.com> <47151960$1@clear.net.nz> <1192567543.848068.5810@v23g2000prn.googlegroups.com> <ff49so$gi9$1@news.hs-bremen.de> <1192604043.431333.236710@q3g2000prf.googlegroups.com> User-Agent: KNode/0.10.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit Lines: 105 Organization: -= Belgacom Usenet Service =- NNTP-Posting-Host: 9d77bded.news.skynet.be X-Trace: 1192607097 news.skynet.be 22305 194.78.198.49:62753 X-Complaints-To: usenet-abuse@skynet.be Xref: prodigy.net comp.arch.fpga:137156 Antti wrote: > On 17 Okt., 08:32, backhus <n...@nirgends.xyz> wrote: >> Antti schrieb: >> >> >> >> > On 16 Okt., 22:05, Jim Granville <no.s...@designtools.maps.co.nz> >> > wrote: >> >> Antti wrote: >> >>> On 16 Okt., 20:44, Jim Granville <no.s...@designtools.maps.co.nz> >> >>>> I take it if you drive 20 leds, they would all exhibit this >> >>>> operation ? - and that you did apply a fix, that cured it - and such >> >>>> Fix must be applied in SW, as you said the PCB/HW/FPGA are all OK ? >> >>>> -jg- Zitierten Text ausblenden - >> >>>> - Zitierten Text anzeigen - >> >>> Jim, >> >>> logic is correct, Vccio ok, no pin cell level strangeness either. >> >>> if I connect the signals that driver led1 and led2 to more LEDs then >> >>> each of them would have similar behaviour as LED1/LED2 depenging what >> >>> signal is driving them. >> >> You did not reply to where SW Fix was, but I see more information is >> >> given in c.a.e ?! >> >> >> Seems like this is not a FPGA 'fault' at all, if code in a >> >> not-before-mentioned AVR can cure it ? >> >> >> <paste> Antii : >> >> > I did originally posted to C.A.F. so sorry for copy to .embedded I >> >> > only do repost here as realized later that well, the FPGA is made >> >> > to look like working wrong by an Atmel AVR MCU. And the "problem" >> >> > is small piece of code that executes on ATmega8. In the matter of >> >> > fact its only 1 wrong bit in the Atmel code, by changing one bit in >> >> > the Atmel code the FPGA code would work as it is supposed to work. >> >> >> So are we to presume this AVR is providing the stimulus signals, that >> >> route thru the working FPGA, and that some Port/RMW issue in the AVR >> >> is >> >> the culprit ? >> >> >> -jg- Zitierten Text ausblenden - >> >> >> - Zitierten Text anzeigen - >> >> > Hi Jim >> >> > yes the PCB has FPGA(Actel) and MCU(AVR) on it, the 1 second blink is >> > generated with the MCU. >> >> > the "issue" appeared when i was debugging an FPGA internal signal, I >> > connected that signal to IO (LED2) >> > LED2 indicated that my FPGA was not working properly (it was that big >> > code that takes 99% of that FPGA). >> >> > then i connected 1 second blink generated by the Atmel to LED2. >> >> > and then i did observe the behaviour as described in the original >> > posting. >> >> > and yes, when I finally found the issue, i changed 1 bit in the AVR >> > firmware and then LEDs did work as they are supposed to work, that is >> > signal driving LED2 was no longer have influence on LED1. >> >> > Antti >> >> Hi Antti, >> so there's an extra MCU involved. Who could guess that from your >> original posting. And you could solve the issue by changing the code in >> the MCU. Well now it makes sense that everything with the VHDL and FPGA >> and even the PCB and power is ok. >> >> So let me give a try on a 6 letter word: >> ENABLE >> >> By some chance your 1 sec Signal (or some other signal from the cpu that >> is synchronous to this one) is continously enabling (and disabling) the >> big Logic, causing the test signal to blink with the same frequency. >> >> Eilert- Zitierten Text ausblenden - >> >> - Zitierten Text anzeigen - > > Hi morning > > we are getting little closer > > ENABLE is not the word, but first letter is the same :) > > the 1 second signal doesnt actually enable or disable the logic in the > FPGA the logic remains functional, no matter the signal value > > the MCU was really generating a "test debug led blink signal" and i > expected that signal to work as such, but it had this described side- > effect, of controlling another output depending on the out value of > that port. If an MCU is involved, and if the issue has been fixed by changing a single bit in the MCU 'code' (I suppose you mean the binary firmware once compiled), this might change the problem quite a lot. Just a wild guess at the 'magic 6-letter word staring with E', does the AVR EEPROM save fuse (EESAVE) play a role ? Did you forget to clear or rewrite the EEPROM which resulted in a different system behavior ? Laurent PinchartArticle: 125165
On 17 Okt., 09:44, Laurent Pinchart <laurent.pinch...@skynet.be> wrote: > Antti wrote: > > On 17 Okt., 08:32, backhus <n...@nirgends.xyz> wrote: > >> Antti schrieb: > > >> > On 16 Okt., 22:05, Jim Granville <no.s...@designtools.maps.co.nz> > >> > wrote: > >> >> Antti wrote: > >> >>> On 16 Okt., 20:44, Jim Granville <no.s...@designtools.maps.co.nz> > >> >>>> I take it if you drive 20 leds, they would all exhibit this > >> >>>> operation ? - and that you did apply a fix, that cured it - and such > >> >>>> Fix must be applied in SW, as you said the PCB/HW/FPGA are all OK ? > >> >>>> -jg- Zitierten Text ausblenden - > >> >>>> - Zitierten Text anzeigen - > >> >>> Jim, > >> >>> logic is correct, Vccio ok, no pin cell level strangeness either. > >> >>> if I connect the signals that driver led1 and led2 to more LEDs then > >> >>> each of them would have similar behaviour as LED1/LED2 depenging what > >> >>> signal is driving them. > >> >> You did not reply to where SW Fix was, but I see more information is > >> >> given in c.a.e ?! > > >> >> Seems like this is not a FPGA 'fault' at all, if code in a > >> >> not-before-mentioned AVR can cure it ? > > >> >> <paste> Antii : > >> >> > I did originally posted to C.A.F. so sorry for copy to .embedded I > >> >> > only do repost here as realized later that well, the FPGA is made > >> >> > to look like working wrong by an Atmel AVR MCU. And the "problem" > >> >> > is small piece of code that executes on ATmega8. In the matter of > >> >> > fact its only 1 wrong bit in the Atmel code, by changing one bit in > >> >> > the Atmel code the FPGA code would work as it is supposed to work. > > >> >> So are we to presume this AVR is providing the stimulus signals, that > >> >> route thru the working FPGA, and that some Port/RMW issue in the AVR > >> >> is > >> >> the culprit ? > > >> >> -jg- Zitierten Text ausblenden - > > >> >> - Zitierten Text anzeigen - > > >> > Hi Jim > > >> > yes the PCB has FPGA(Actel) and MCU(AVR) on it, the 1 second blink is > >> > generated with the MCU. > > >> > the "issue" appeared when i was debugging an FPGA internal signal, I > >> > connected that signal to IO (LED2) > >> > LED2 indicated that my FPGA was not working properly (it was that big > >> > code that takes 99% of that FPGA). > > >> > then i connected 1 second blink generated by the Atmel to LED2. > > >> > and then i did observe the behaviour as described in the original > >> > posting. > > >> > and yes, when I finally found the issue, i changed 1 bit in the AVR > >> > firmware and then LEDs did work as they are supposed to work, that is > >> > signal driving LED2 was no longer have influence on LED1. > > >> > Antti > > >> Hi Antti, > >> so there's an extra MCU involved. Who could guess that from your > >> original posting. And you could solve the issue by changing the code in > >> the MCU. Well now it makes sense that everything with the VHDL and FPGA > >> and even the PCB and power is ok. > > >> So let me give a try on a 6 letter word: > >> ENABLE > > >> By some chance your 1 sec Signal (or some other signal from the cpu that > >> is synchronous to this one) is continously enabling (and disabling) the > >> big Logic, causing the test signal to blink with the same frequency. > > >> Eilert- Zitierten Text ausblenden - > > >> - Zitierten Text anzeigen - > > > Hi morning > > > we are getting little closer > > > ENABLE is not the word, but first letter is the same :) > > > the 1 second signal doesnt actually enable or disable the logic in the > > FPGA the logic remains functional, no matter the signal value > > > the MCU was really generating a "test debug led blink signal" and i > > expected that signal to work as such, but it had this described side- > > effect, of controlling another output depending on the out value of > > that port. > > If an MCU is involved, and if the issue has been fixed by changing a single > bit in the MCU 'code' (I suppose you mean the binary firmware once > compiled), this might change the problem quite a lot. Just a wild guess at > the 'magic 6-letter word staring with E', does the AVR EEPROM save fuse > (EESAVE) play a role ? Did you forget to clear or rewrite the EEPROM which > resulted in a different system behavior ? > > Laurent Pinchart- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - ROTFL the guesses are getting better and better. I happen to have written the first ever released commercial AVR compiler ever (it was on market 30 days after first AT90S1200 was ever sold), the 1 bit error is in AVR program compiled with this compiler (AVR Basic compiler) and no, if the problem is not caused by an BUG in the compiler ;) OK, here is the code in AVR basic that executes on the ATmega8 // CODE WITH ERROR, //LED1 and LED2 blink if some_signal=1, //LED2 blinks, LED1 off whne some_signal=0 loop: sendbyte($40); // set LED2 ON wait_1sec; sendbyte($00); // set LED2 OFF wait_1sec; goto loop // FIXED CODE, // LED2 blinks, LED1 is controlled by state of some_signal loop: sendbyte($40); // set LED2 ON wait_1sec; sendbyte($10); // set LED2 OFF wait_1sec; goto loop as you see the "fix" is exactly 1 bit !!! Antti here and in other place signal-wire-label-function names are changed from the original onesArticle: 125166
Hello all:) I am running a design in edk 6.1 version. and comes up with " Makefile cannot be saved to run process. Please ensure IPs in MHS file point to the right MPDs". The MHS doesnt contain info about MPDs.. What i have to do on that? regardsArticle: 125167
Hello everyone, in our company we're using FPGA Advantage of Mentor Graphics to develop FPGA design. The Boss ask for an "higher level" work flow than RTL level. Do someone give me some information about that? What about CatapultC? Are there tool vendor indipendent? Thanks for your support, regardsArticle: 125168
Antti wrote: > On 17 Okt., 09:44, Laurent Pinchart <laurent.pinch...@skynet.be> > wrote: > >>Antti wrote: >> >>>On 17 Okt., 08:32, backhus <n...@nirgends.xyz> wrote: >>> >>>>Antti schrieb: >> >>>>>On 16 Okt., 22:05, Jim Granville <no.s...@designtools.maps.co.nz> >>>>>wrote: >>>>> >>>>>>Antti wrote: >>>>>> >>>>>>>On 16 Okt., 20:44, Jim Granville <no.s...@designtools.maps.co.nz> >>>>>>> >>>>>>>>I take it if you drive 20 leds, they would all exhibit this >>>>>>>>operation ? - and that you did apply a fix, that cured it - and such >>>>>>>>Fix must be applied in SW, as you said the PCB/HW/FPGA are all OK ? >>>>>>>>-jg- Zitierten Text ausblenden - >>>>>>>>- Zitierten Text anzeigen - >>>>>>> >>>>>>>Jim, >>>>>>>logic is correct, Vccio ok, no pin cell level strangeness either. >>>>>>>if I connect the signals that driver led1 and led2 to more LEDs then >>>>>>>each of them would have similar behaviour as LED1/LED2 depenging what >>>>>>>signal is driving them. >>>>>> >>>>>>You did not reply to where SW Fix was, but I see more information is >>>>>>given in c.a.e ?! >> >>>>>>Seems like this is not a FPGA 'fault' at all, if code in a >>>>>>not-before-mentioned AVR can cure it ? >> >>>>>><paste> Antii : >>>>>> > I did originally posted to C.A.F. so sorry for copy to .embedded I >>>>>> > only do repost here as realized later that well, the FPGA is made >>>>>> > to look like working wrong by an Atmel AVR MCU. And the "problem" >>>>>> > is small piece of code that executes on ATmega8. In the matter of >>>>>> > fact its only 1 wrong bit in the Atmel code, by changing one bit in >>>>>> > the Atmel code the FPGA code would work as it is supposed to work. >> >>>>>>So are we to presume this AVR is providing the stimulus signals, that >>>>>>route thru the working FPGA, and that some Port/RMW issue in the AVR >>>>>>is >>>>>>the culprit ? >> >>>>>>-jg- Zitierten Text ausblenden - >> >>>>>>- Zitierten Text anzeigen - >> >>>>>Hi Jim >> >>>>>yes the PCB has FPGA(Actel) and MCU(AVR) on it, the 1 second blink is >>>>>generated with the MCU. >> >>>>>the "issue" appeared when i was debugging an FPGA internal signal, I >>>>>connected that signal to IO (LED2) >>>>>LED2 indicated that my FPGA was not working properly (it was that big >>>>>code that takes 99% of that FPGA). >> >>>>>then i connected 1 second blink generated by the Atmel to LED2. >> >>>>>and then i did observe the behaviour as described in the original >>>>>posting. >> >>>>>and yes, when I finally found the issue, i changed 1 bit in the AVR >>>>>firmware and then LEDs did work as they are supposed to work, that is >>>>>signal driving LED2 was no longer have influence on LED1. >> >>>>>Antti >> >>>>Hi Antti, >>>>so there's an extra MCU involved. Who could guess that from your >>>>original posting. And you could solve the issue by changing the code in >>>>the MCU. Well now it makes sense that everything with the VHDL and FPGA >>>>and even the PCB and power is ok. >> >>>>So let me give a try on a 6 letter word: >>>>ENABLE >> >>>>By some chance your 1 sec Signal (or some other signal from the cpu that >>>>is synchronous to this one) is continously enabling (and disabling) the >>>>big Logic, causing the test signal to blink with the same frequency. >> >>>>Eilert- Zitierten Text ausblenden - >> >>>>- Zitierten Text anzeigen - >> >>>Hi morning >> >>>we are getting little closer >> >>>ENABLE is not the word, but first letter is the same :) >> >>>the 1 second signal doesnt actually enable or disable the logic in the >>>FPGA the logic remains functional, no matter the signal value >> >>>the MCU was really generating a "test debug led blink signal" and i >>>expected that signal to work as such, but it had this described side- >>>effect, of controlling another output depending on the out value of >>>that port. >> >>If an MCU is involved, and if the issue has been fixed by changing a single >>bit in the MCU 'code' (I suppose you mean the binary firmware once >>compiled), this might change the problem quite a lot. Just a wild guess at >>the 'magic 6-letter word staring with E', does the AVR EEPROM save fuse >>(EESAVE) play a role ? Did you forget to clear or rewrite the EEPROM which >>resulted in a different system behavior ? >> >>Laurent Pinchart- Zitierten Text ausblenden - >> >>- Zitierten Text anzeigen - > > > ROTFL > the guesses are getting better and better. > > I happen to have written the first ever released commercial AVR > compiler ever > (it was on market 30 days after first AT90S1200 was ever sold), the 1 > bit error > is in AVR program compiled with this compiler (AVR Basic compiler) > and no, if the problem is not caused by an BUG in the compiler ;) > > OK, here is the code in AVR basic that executes on the ATmega8 > > > // CODE WITH ERROR, > //LED1 and LED2 blink if some_signal=1, > //LED2 blinks, LED1 off whne some_signal=0 > loop: > sendbyte($40); // set LED2 ON > wait_1sec; > sendbyte($00); // set LED2 OFF > wait_1sec; > goto loop > > // FIXED CODE, > // LED2 blinks, LED1 is controlled by state of some_signal > loop: > sendbyte($40); // set LED2 ON > wait_1sec; > sendbyte($10); // set LED2 OFF > wait_1sec; > goto loop > > as you see the "fix" is exactly 1 bit !!! So the fixed one creates a balanced signal, whilst error is single ended. The fixed one also has at least one bit high on the port. You have not identified which of these port bits map to CLK and LED operations. -jgArticle: 125169
Are all the pins involved 'normal' I/O pins, without any shared functionality such as JTAG - if so, what kind of pins? Does sendbyte control 8 separate i/o pins / does sendbyte have any side-effects? Doug On Oct 17, 10:57 am, Antti <Antti.Luk...@googlemail.com> wrote: > > ROTFL > the guesses are getting better and better. > > I happen to have written the first ever released commercial AVR > compiler ever > (it was on market 30 days after first AT90S1200 was ever sold), the 1 > bit error > is in AVR program compiled with this compiler (AVR Basic compiler) > and no, if the problem is not caused by an BUG in the compiler ;) > > OK, here is the code in AVR basic that executes on the ATmega8 > > // CODE WITH ERROR, > //LED1 and LED2 blink if some_signal=1, > //LED2 blinks, LED1 off whne some_signal=0 > loop: > sendbyte($40); // set LED2 ON > wait_1sec; > sendbyte($00); // set LED2 OFF > wait_1sec; > goto loop > > // FIXED CODE, > // LED2 blinks, LED1 is controlled by state of some_signal > loop: > sendbyte($40); // set LED2 ON > wait_1sec; > sendbyte($10); // set LED2 OFF > wait_1sec; > goto loop > > as you see the "fix" is exactly 1 bit !!! > > Antti > here and in other place signal-wire-label-function names are changed > from the original ones- Hide quoted text - > > - Show quoted text -Article: 125170
Hi, Are all the i/o pins involved "normal" pins without any shared/special functionality such as JTAG, CLK etc? If so, what? Does sendbyte control 8 separate i/o pins? Are they all configured as inputs? Does sendbyte have any side-effects? How's the wiring between AVR and FPGA in all related signals? 6-letter magic e-word suggestions: Encode, Energy, EXTEST. -Doug On Oct 17, 10:57 am, Antti <Antti.Luk...@googlemail.com> wrote: > ROTFL > the guesses are getting better and better. > > I happen to have written the first ever released commercial AVR > compiler ever > (it was on market 30 days after first AT90S1200 was ever sold), the 1 > bit error > is in AVR program compiled with this compiler (AVR Basic compiler) > and no, if the problem is not caused by an BUG in the compiler ;) > > OK, here is the code in AVR basic that executes on the ATmega8 > > // CODE WITH ERROR, > //LED1 and LED2 blink if some_signal=1, > //LED2 blinks, LED1 off whne some_signal=0 > loop: > sendbyte($40); // set LED2 ON > wait_1sec; > sendbyte($00); // set LED2 OFF > wait_1sec; > goto loop > > // FIXED CODE, > // LED2 blinks, LED1 is controlled by state of some_signal > loop: > sendbyte($40); // set LED2 ON > wait_1sec; > sendbyte($10); // set LED2 OFF > wait_1sec; > goto loop > > as you see the "fix" is exactly 1 bit !!! > > Antti > here and in other place signal-wire-label-function names are changed > from the original onesArticle: 125171
Hi,
You should maybe start by the 58th Xcell Journal, dedicated to ESL
tools.
good luck
csb
On 17 oct, 10:50, Maroc <md2...@libero.it> wrote:
> Hello everyone,
>
> in our company we're using FPGA Advantage of Mentor Graphics to
> develop FPGA design.
> The Boss ask for an "higher level" work flow than RTL level.
> Do someone give me some information about that?
>
> What about CatapultC?
>
> Are there tool vendor indipendent?
>
> Thanks for your support,
>
> regards
Article: 125172On 17 Okt., 11:22, Douglas <j.d.morri...@gmail.com> wrote: > Hi, > > Are all the i/o pins involved "normal" pins without any shared/special > functionality such as JTAG, CLK etc? If so, what? Does sendbyte > control 8 separate i/o pins? Are they all configured as inputs? Does > sendbyte have any side-effects? How's the wiring between AVR and FPGA > in all related signals? > > 6-letter magic e-word suggestions: Encode, Energy, EXTEST. > > -Doug and we have a WINNER, please contact me in private you will get an FPGA miniconsole from the first production batch. the magic word is EXTEST and all others please stand by, I may have some second prizes to offer as well, and I will post here some longer explanation how this "issue" happened in the first place. and yes the explanation is very plausible, the blink_one_led was connected to port named UIREG6 of the UJTAG primitive of Actel ProAsic3 FPGA 0x40 was used by the MCU to set the UIREG6 to high, it made the LED2 on. now the LED off should have been 0x10 (or some other value in range 16-127) to keep the IR register content in "user instruction" range, but I accidentitally just cleared bit 6, so the instruction i sent for LED2 off as 0x00 - EXTEST so that explains it all. no mystery. nothing wrong, expect small human error in some coding. AnttiArticle: 125173
On Wed, 17 Oct 2007 07:57:23 -0000, Antti <Antti.Lukats@googlemail.com> wrote: >// CODE WITH ERROR, >//LED1 and LED2 blink if some_signal=1, >//LED2 blinks, LED1 off whne some_signal=0 >loop: > sendbyte($40); // set LED2 ON > wait_1sec; > sendbyte($00); // set LED2 OFF > wait_1sec; > goto loop > >// FIXED CODE, >// LED2 blinks, LED1 is controlled by state of some_signal >loop: > sendbyte($40); // set LED2 ON > wait_1sec; > sendbyte($10); // set LED2 OFF > wait_1sec; > goto loop The LED output drivers are bidirectional, and bit 6 is the active-low output enable for both LEDs. Two other bits are the active-high data bits for the 2 LEDs (bit4 is LED1). Bad code: $40 -> outputs disabled, both LEDs turn on via an IOB pullup $00 -> outputs enabled, data bits 0, both LEDs off ie. both LEDs flash Good code: $40 -> outputs disabled, both LEDs turn on via an IOB pullup $10 -> outputs enabled, LED1 on because bit 4 is 1, LED2 off because bitX is 0 ?Article: 125174
On Oct 16, 9:42 pm, morphiend <morphi...@gmail.com> wrote: > On Oct 16, 11:30 am, Antti <Antti.Luk...@googlemail.com> wrote: > > > > > > > On 16 Okt., 17:26, morphiend <morphi...@gmail.com> wrote: > > > > On Oct 16, 5:21 am, avrba...@hotmail.com wrote: > > > > > On 16 Okt., 10:17, Laurent Pinchart <laurent.pinch...@skynet.be> > > > > wrote: > > > > > > Antti wrote: > > > > > > On 16 Okt., 09:51, Laurent Pinchart <laurent.pinch...@skynet.be> > > > > > > wrote: > > > > > >> Antti wrote: > > > > > >> > Xilinx Spartan3A on custom PCB. > > > > > >> > was working ok > > > > > >> > was stressed VCCINT=1.8V (regulator IC current limit 150ma) > > > > > >> > it does configure ok from external configuration memory > > > > > > >> > JTAG scan returns JTAGID from Virtex-II family. > > > > > > >> > what is wrong? > > > > > > >> Delays in the JTAG chain that shift the data by 1 bit ? Was the JTAGID > > > > > >> manufacturer field still the Xilinx ID ? > > > > > > >> Laurent Pinchart > > > > > > > JTAG ID returned > > > > > > vendor Xilinx > > > > > > family Virtex-II > > > > > > device 0 (invalid) > > > > > > > this same (wrong!) JTAGID returned all the time > > > > > > TDO driven by more than one component ? If two Xilinx parts drive TDO in > > > > > sync (instead of being properly chained) conflicts will occur for the > > > > > family and device ID by not the vendor ID. > > > > > > Laurent Pinchart- Zitierten Text ausblenden - > > > > > > - Zitierten Text anzeigen - > > > > > single IC chain > > > > Single IC chain, but is there more than one entity on the chain, say a > > > V2 before/after it. If so, the spartan could have stuck itself in > > > constant pass-through and the other device was the only one responding > > > on the chain. > > > > -- Mike- Zitierten Text ausblenden - > > > > - Zitierten Text anzeigen - > > > single chain, single TAP entity in the chain > > > Antti > > Is it possible that voltage feed for the ID code is sourced from two > different locations inside the FPGA and that the first part of the ID > is generated properly but the latter becomes erased/garbled?- Hide quoted text - > > - Show quoted text - Recheck decoupling capacitors and power destribution on the board. if you want to avoid this error, assign boundary scan descriptive language file (of spartan 3A) to FPGA in IMPACT. Hope it won't help.... :-), but i solved my problem this way. MH
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