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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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 125150

Article: 125150
Subject: Re: Xilinx timing constraints incorrect?
From: Duane Clark <junkmail@junkmail.com>
Date: Tue, 16 Oct 2007 13:06:44 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: FPGA quiz: what can be wrong
From: Antti <Antti.Lukats@googlemail.com>
Date: Tue, 16 Oct 2007 20:45:43 -0000
Links: << >>  << T >>  << A >>
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


Article: 125152
Subject: Re: Xilinx timing constraints incorrect?
From: paragon.john@gmail.com
Date: Tue, 16 Oct 2007 21:12:44 -0000
Links: << >>  << T >>  << A >>
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
Subject: Re: Quartus II Web Edition License - SOPC Builder generation?
From: sendthis@gmail.com
Date: Tue, 16 Oct 2007 14:17:46 -0700
Links: << >>  << T >>  << A >>
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!
Eric


Article: 125154
Subject: Re: Xilinx timing constraints incorrect?
From: Mike Treseler <mike_treseler@comcast.net>
Date: Tue, 16 Oct 2007 14:31:38 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: FPGA quiz: what can be wrong
From: "MM" <mbmsv@yahoo.com>
Date: Tue, 16 Oct 2007 20:03:42 -0400
Links: << >>  << T >>  << A >>
> 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 



Article: 125156
Subject: gold code - seed value
From: Manny <mloulah@hotmail.com>
Date: Tue, 16 Oct 2007 21:33:16 -0700
Links: << >>  << T >>  << A >>
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,
Manny


Article: 125157
Subject: Re: FPGA quiz: what can be wrong
From: Antti <Antti.Lukats@googlemail.com>
Date: Wed, 17 Oct 2007 04:37:18 -0000
Links: << >>  << T >>  << A >>
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
Subject: Re: gold code - seed value
From: Mike Treseler <mike_treseler@comcast.net>
Date: Tue, 16 Oct 2007 22:11:18 -0700
Links: << >>  << T >>  << A >>
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+seed

Article: 125159
Subject: Re: FPGA quiz: what can be wrong
From: Thomas Stanka <usenet_nospam_valid@stanka-web.de>
Date: Tue, 16 Oct 2007 22:18:14 -0700
Links: << >>  << T >>  << A >>
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


Article: 125160
Subject: Re: FPGA quiz: what can be wrong
From: Antti <Antti.Lukats@googlemail.com>
Date: Wed, 17 Oct 2007 05:30:00 -0000
Links: << >>  << T >>  << A >>
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 buffer




Article: 125161
Subject: Re: FPGA quiz: what can be wrong
From: "Sylvain Munaut <SomeOne@SomeDomain.com>" <246tnt@gmail.com>
Date: Wed, 17 Oct 2007 06:15:56 -0000
Links: << >>  << T >>  << A >>
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


Article: 125162
Subject: Re: FPGA quiz: what can be wrong
From: Antti <Antti.Lukats@googlemail.com>
Date: Wed, 17 Oct 2007 06:26:27 -0000
Links: << >>  << T >>  << A >>
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


Antti


Article: 125163
Subject: Re: FPGA quiz: what can be wrong
From: backhus <nix@nirgends.xyz>
Date: Wed, 17 Oct 2007 08:32:16 +0200
Links: << >>  << T >>  << A >>
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

Article: 125164
Subject: Re: FPGA quiz: what can be wrong
From: Antti <Antti.Lukats@googlemail.com>
Date: Wed, 17 Oct 2007 06:54:03 -0000
Links: << >>  << T >>  << A >>
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 Pinchart


Article: 125165
Subject: Re: FPGA quiz: what can be wrong
From: Antti <Antti.Lukats@googlemail.com>
Date: Wed, 17 Oct 2007 07:57:23 -0000
Links: << >>  << T >>  << A >>
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 ones


Article: 125166
Subject: IPs in MHS file
From: xenix <lastval@gmail.com>
Date: Wed, 17 Oct 2007 08:29:36 -0000
Links: << >>  << T >>  << A >>
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?

regards


Article: 125167
Subject: High level FPGA work flow: available tool?
From: Maroc <md2003@libero.it>
Date: Wed, 17 Oct 2007 01:50:15 -0700
Links: << >>  << T >>  << A >>
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: 125168
Subject: Re: FPGA quiz: what can be wrong
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Wed, 17 Oct 2007 21:51:43 +1300
Links: << >>  << T >>  << A >>
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.

-jg




Article: 125169
Subject: Re: FPGA quiz: what can be wrong
From: Douglas <j.d.morrison@gmail.com>
Date: Wed, 17 Oct 2007 09:11:47 -0000
Links: << >>  << T >>  << A >>

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
Subject: Re: FPGA quiz: what can be wrong
From: Douglas <j.d.morrison@gmail.com>
Date: Wed, 17 Oct 2007 09:22:08 -0000
Links: << >>  << T >>  << A >>

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 ones


Article: 125171
Subject: Re: High level FPGA work flow: available tool?
From: csantos <cayetanosantos@gmail.com>
Date: Wed, 17 Oct 2007 09:29:40 -0000
Links: << >>  << T >>  << A >>
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: 125172
Subject: Re: FPGA quiz: what can be wrong
From: Antti <Antti.Lukats@googlemail.com>
Date: Wed, 17 Oct 2007 09:42:08 -0000
Links: << >>  << T >>  << A >>
On 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.

Antti


Article: 125173
Subject: Re: FPGA quiz: what can be wrong
From: Evan Lavelle <nospam@nospam.com>
Date: Wed, 17 Oct 2007 10:45:52 +0100
Links: << >>  << T >>  << A >>
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
Subject: Re: FPGA quiz2: spartan3A return Virtex JTAGID. Also prizes for quiz1 and quiz2
From: mh <moazzamhussain@gmail.com>
Date: Wed, 17 Oct 2007 03:38:17 -0700
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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