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 125100

Article: 125100
Subject: Re: FPGA quiz2: spartan3A return Virtex JTAGID. Also prizes for quiz1 and quiz2
From: Antti <Antti.Lukats@googlemail.com>
Date: Tue, 16 Oct 2007 11:45:03 -0000
Links: << >>  << T >>  << A >>
On 16 Okt., 13:42, Laurent Pinchart <laurent.pinch...@skynet.be>
wrote:
>  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
>
> > Antti
> > (sorry for posting from different account, google goups asserted temp.
> > block on my primary account)
>
> Could the family and device ID be stored as some kind of fuses that got
> burnt when VCCINT was raised to 1.8V ?
>
> Laurent Pinchart- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

it was my first guess too, but no this is not the case

Antti




Article: 125101
Subject: FPGA to FPGA Bus
From: "maxascent" <maxascent@yahoo.co.uk>
Date: Tue, 16 Oct 2007 06:48:08 -0500
Links: << >>  << T >>  << A >>

Hi

I would like to connect 3 FPGA devices together using a 32-bit bus. Also I
would like all 3 to be masters on the bus. Is there any standard bus out
there that would do this rather than me coming up with my own idea. 

Jon

Article: 125102
Subject: Re: FPGA quiz: what can be wrong
From: "Amontec, Larry" <laurent.gauch@ANTI-SPAMamontec.com>
Date: Tue, 16 Oct 2007 13:48:42 +0200
Links: << >>  << T >>  << A >>
Amontec, Larry wrote:

> Antti wrote:
> 
>> vhdl code
>>
>> LED1 <= some_signal;
>> LED2 <= blink_one_second;
>>
>> the LED1,2 are connected to LED's
>> blink_one_second is simple wire that drives LED2 and nothing else.
>>
>> now the code works in real FPGA with following behaviour:
>>
>> when some_signal = 0, then LED2 blinks.
>> when some_signal = 1, then both LEDs blink as full sync to each other.
>>
>> what can cause this?
>>
>> some wrong answers: faulty FPGA fabric, bad PCB, bad power supply.
>>
>> eh, the solution to the problem was weird. but it does exist. sure I
>> assumed FPGA fabric faulty first as I had overstressed the FPGA with
>> 5V supply, and reversed 3.3V supply too. but FPGA is alive and fully
>> working, yet the weird behaviour exist. and this is actually correct
>> behaviour in the particular case.
>>
>> I wonder if somebody is able to quess the answer to the issue. happy
>> thinking!
>>
>> Antti
>>
> 
> Not the VHDL
> Not the UCF
> Not the synth.
> Not the P/R
> Not FPGA fabric
> Not the supply
> Not the PCB
> Not the Led
> Not the FPGA version
> Not the FPGA vendor
> Not the DCI
> Not the DCM
> Not the Ground Loop
> Not Coupling issue
> Not the LED itself
> ...
> 
> Maybe in Absolute Maximum Rating ?
> You are stocking your FPGA boards under -65 Celcius ;-) (storage 
> temperature) just funny
> 
> ----------------------
> More serious: Junction temperature ?
> ----------------------
> 
> - Laurent
>   www.amontec.com

Please let us a VHDL example or a partial VHDL.
Then we will p&r to our FPGAs Platform, and we will see !

---------------
You do not test all conditions in your VHDL -> then synth. uses some 
async D-latch?
---------------

BUT THIS IS A STUDENT-ISSUE KIND -> NOT AN ANTTI-ISSUE

-----------

  - Laurent
    www.amontec.com

Article: 125103
Subject: Re: FPGA quiz: what can be wrong
From: Brian Davis <brimdavis@aol.com>
Date: Tue, 16 Oct 2007 04:56:18 -0700
Links: << >>  << T >>  << A >>
Antti wrote:
>
> the io banking is not issue
> the io standard is ir-relevant
> also not the supply to different banks
> there is no opto coupling issue
> the same behaviour on pads could be observed with no connections (no
> LED)
>

 Is one of the signals involved connected to a global
tristate or powerdown pin on the FPGA ?

Brian


Article: 125104
Subject: Re: FPGA to FPGA Bus
From: Uncle Noah <nkavv@skiathos.physics.auth.gr>
Date: Tue, 16 Oct 2007 05:00:41 -0700
Links: << >>  << T >>  << A >>
On Oct 16, 2:48 pm, "maxascent" <maxasc...@yahoo.co.uk> wrote:
> Hi
>
> I would like to connect 3 FPGA devices together using a 32-bit bus. Also I
> would like all 3 to be masters on the bus. Is there any standard bus out
> there that would do this rather than me coming up with my own idea.
>
> Jon

Search for hypertunnel (HT) chip-to-chip bus.

There is a chance that an HT implementation is at the OpenCores site.

Nikolaos Kavvadias


Article: 125105
Subject: Re: FPGA quiz: what can be wrong
From: Antti <Antti.Lukats@googlemail.com>
Date: Tue, 16 Oct 2007 12:02:45 -0000
Links: << >>  << T >>  << A >>
On 16 Okt., 13:56, Brian Davis <brimda...@aol.com> wrote:
> Antti wrote:
>
> > the io banking is not issue
> > the io standard is ir-relevant
> > also not the supply to different banks
> > there is no opto coupling issue
> > the same behaviour on pads could be observed with no connections (no
> > LED)
>
>  Is one of the signals involved connected to a global
> tristate or powerdown pin on the FPGA ?
>
> Brian

wau, keep getting nice suggestions! :)
no power down or FPGA power management is not the issue

Antti




Article: 125106
Subject: Re: FPGA quiz: what can be wrong
From: Philip Potter <pgp@see.sig.invalid>
Date: Tue, 16 Oct 2007 13:10:03 +0100
Links: << >>  << T >>  << A >>
Antti wrote:
> On 16 Okt., 13:01, Philip Potter <p...@see.sig.invalid> wrote:
>> Antti wrote:
>>> vhdl code
>>> LED1 <= some_signal;
>>> LED2 <= blink_one_second;
>>> the LED1,2 are connected to LED's
>>> blink_one_second is simple wire that drives LED2 and nothing else.
>>> now the code works in real FPGA with following behaviour:
>>> when some_signal = 0, then LED2 blinks.
>>> when some_signal = 1, then both LEDs blink as full sync to each other.
>>> what can cause this?
>>> some wrong answers: faulty FPGA fabric, bad PCB, bad power supply.
>>> eh, the solution to the problem was weird. but it does exist. sure I
>>> assumed FPGA fabric faulty first as I had overstressed the FPGA with
>>> 5V supply, and reversed 3.3V supply too. but FPGA is alive and fully
>>> working, yet the weird behaviour exist. and this is actually correct
>>> behaviour in the particular case.
>>> I wonder if somebody is able to quess the answer to the issue. happy
>>> thinking!
>>> Antti
>> I don't understand. You have said:
>>
>> * No problem in VHDL, constraints, and all other FPGA files
>> * No problem in configuration
>> * No problem in PCB, power supply, connections, wiring.
>>
>> When you say the VHDL file is "correct", to what specification does it
>> conform? You haven't said what you *expect* or *require* the VHDL to do.
>>   It looks like it should output some_signal to LED1 and
>> blink_one_second to LED2 - but this isn't the case when the FPGA is
>> configured.
>>
>> What happens if you remove the blink_one_second signal completely? Does
>> LED1 still blink?
>>
>> --
>> Philip Potter pgp <at> doc.ic.ac.uk- Zitierten Text ausblenden -
>>
>> - Zitierten Text anzeigen -
> 
> the VHDL code driving LED when entered in schematic would be a single
> line going to LED2,

This doesn't obviously answer my question. You don't mention LED1 in 
your description of the schematic.

> the signal driving LED2 could be disconnected from LED2 IOB or
> connected to some other IO or anything else, the LED1 would still have
> the same behaviour, it would blink in sync with the signal that was
> driving LED2  if some_signal is high, and be constant low if
> some_signal is 0

If you change the frequency of blink_one_second does the other LED 
change frequency with it?

-- 
Philip Potter pgp <at> doc.ic.ac.uk

Article: 125107
Subject: Re: FPGA quiz: what can be wrong
From: Antti <Antti.Lukats@googlemail.com>
Date: Tue, 16 Oct 2007 12:10:18 -0000
Links: << >>  << T >>  << A >>
On 16 Okt., 13:48, "Amontec, Larry" <laurent.ga...@ANTI-
SPAMamontec.com> wrote:
> Amontec, Larry wrote:
> > Antti wrote:
>
> >> vhdl code
>
> >> LED1 <= some_signal;
> >> LED2 <= blink_one_second;
>
> >> the LED1,2 are connected to LED's
> >> blink_one_second is simple wire that drives LED2 and nothing else.
>
> >> now the code works in real FPGA with following behaviour:
>
> >> when some_signal = 0, then LED2 blinks.
> >> when some_signal = 1, then both LEDs blink as full sync to each other.
>
> >> what can cause this?
>
> >> some wrong answers: faulty FPGA fabric, bad PCB, bad power supply.
>
> >> eh, the solution to the problem was weird. but it does exist. sure I
> >> assumed FPGA fabric faulty first as I had overstressed the FPGA with
> >> 5V supply, and reversed 3.3V supply too. but FPGA is alive and fully
> >> working, yet the weird behaviour exist. and this is actually correct
> >> behaviour in the particular case.
>
> >> I wonder if somebody is able to quess the answer to the issue. happy
> >> thinking!
>
> >> Antti
>
> > Not the VHDL
> > Not the UCF
> > Not the synth.
> > Not the P/R
> > Not FPGA fabric
> > Not the supply
> > Not the PCB
> > Not the Led
> > Not the FPGA version
> > Not the FPGA vendor
> > Not the DCI
> > Not the DCM
> > Not the Ground Loop
> > Not Coupling issue
> > Not the LED itself
> > ...
>
> > Maybe in Absolute Maximum Rating ?
> > You are stocking your FPGA boards under -65 Celcius ;-) (storage
> > temperature) just funny
>
> > ----------------------
> > More serious: Junction temperature ?
> > ----------------------
>
> > - Laurent
> >  www.amontec.com
>
> Please let us a VHDL example or a partial VHDL.
> Then we will p&r to our FPGAs Platform, and we will see !
>
> ---------------
> You do not test all conditions in your VHDL -> then synth. uses some
> async D-latch?
> ---------------
>
> BUT THIS IS A STUDENT-ISSUE KIND -> NOT AN ANTTI-ISSUE
>
> -----------
>
>   - Laurent
>    www.amontec.com- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

Hi Laurent,

the VHDL code for signal LED2 is essentially a single wire point-to-
point it would be single horizontal stright wire in scheamatic
version.

========== cut here ==========

signal blink_one_second : std_logic;

[snip]
  name_of_some_port => blink_one_second; -- connect blink signal to
its source

[snip]
 LED2 <= blink_one_second; -- connec the blink signal to IOB

==== and here ========

the VHDL name blink_one_second appears in the code exactly 3 times

Antti























Article: 125108
Subject: Re: FPGA quiz: what can be wrong
From: Antti <Antti.Lukats@googlemail.com>
Date: Tue, 16 Oct 2007 12:12:27 -0000
Links: << >>  << T >>  << A >>
On 16 Okt., 14:10, Philip Potter <p...@see.sig.invalid> wrote:
> Antti wrote:
> > On 16 Okt., 13:01, Philip Potter <p...@see.sig.invalid> wrote:
> >> Antti wrote:
> >>> vhdl code
> >>> LED1 <= some_signal;
> >>> LED2 <= blink_one_second;
> >>> the LED1,2 are connected to LED's
> >>> blink_one_second is simple wire that drives LED2 and nothing else.
> >>> now the code works in real FPGA with following behaviour:
> >>> when some_signal = 0, then LED2 blinks.
> >>> when some_signal = 1, then both LEDs blink as full sync to each other.
> >>> what can cause this?
> >>> some wrong answers: faulty FPGA fabric, bad PCB, bad power supply.
> >>> eh, the solution to the problem was weird. but it does exist. sure I
> >>> assumed FPGA fabric faulty first as I had overstressed the FPGA with
> >>> 5V supply, and reversed 3.3V supply too. but FPGA is alive and fully
> >>> working, yet the weird behaviour exist. and this is actually correct
> >>> behaviour in the particular case.
> >>> I wonder if somebody is able to quess the answer to the issue. happy
> >>> thinking!
> >>> Antti
> >> I don't understand. You have said:
>
> >> * No problem in VHDL, constraints, and all other FPGA files
> >> * No problem in configuration
> >> * No problem in PCB, power supply, connections, wiring.
>
> >> When you say the VHDL file is "correct", to what specification does it
> >> conform? You haven't said what you *expect* or *require* the VHDL to do.
> >>   It looks like it should output some_signal to LED1 and
> >> blink_one_second to LED2 - but this isn't the case when the FPGA is
> >> configured.
>
> >> What happens if you remove the blink_one_second signal completely? Does
> >> LED1 still blink?
>
> >> --
> >> Philip Potter pgp <at> doc.ic.ac.uk- Zitierten Text ausblenden -
>
> >> - Zitierten Text anzeigen -
>
> > the VHDL code driving LED when entered in schematic would be a single
> > line going to LED2,
>
> This doesn't obviously answer my question. You don't mention LED1 in
> your description of the schematic.
>
> > the signal driving LED2 could be disconnected from LED2 IOB or
> > connected to some other IO or anything else, the LED1 would still have
> > the same behaviour, it would blink in sync with the signal that was
> > driving LED2  if some_signal is high, and be constant low if
> > some_signal is 0
>
> If you change the frequency of blink_one_second does the other LED
> change frequency with it?
>
> --
> Philip Potter pgp <at> doc.ic.ac.uk- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

yes, as long as some_signal is 1, LED1 blinks in sync and same
polarity as LED2, no matter the frequency
if the signal would be derived from human operated button then it
would appear as button is connected to both LEDs

Antti






Article: 125109
Subject: Re: FPGA quiz: what can be wrong
From: MikeShepherd564@btinternet.com
Date: Tue, 16 Oct 2007 13:13:12 +0100
Links: << >>  << T >>  << A >>
Don't you people have anything better to do?  We all come across
puzzling and time-consuming problems where we've made what seems to be
a reasonable assumption but which turns out to be false.  The lesson
is sobering, but the sterile chase after another's problem is little
more than self-indulgence.

As Gauss put it:(when others tempted him to become interested in
Fermat's conjecture):  "I confess that Fermat's Theorem as an isolated
proposition has very little interest for me, because I could easily
lay down a multitude of such propositions, which one could neither
prove nor dispose of".

Article: 125110
Subject: Re: FPGA quiz: what can be wrong
From: Brian Davis <brimdavis@aol.com>
Date: Tue, 16 Oct 2007 05:16:00 -0700
Links: << >>  << T >>  << A >>
Antti wrote:
>
> no power down or FPGA power management is not the issue
>

 Does your exclusion of global tristate and powerdown
pin assignment problems also extend to other global pins,
such as reset?

Would the problem appear in a post-PAR gate level simulation of the
design?

Is one of the signals clocked, and the other strictly combinatorial?

Brian


Article: 125111
Subject: Re: FPGA quiz: what can be wrong
From: Antti <Antti.Lukats@googlemail.com>
Date: Tue, 16 Oct 2007 12:25:30 -0000
Links: << >>  << T >>  << A >>
On 16 Okt., 14:16, Brian Davis <brimda...@aol.com> wrote:
> Antti wrote:
>
> > no power down or FPGA power management is not the issue
>
>  Does your exclusion of global tristate and powerdown
> pin assignment problems also extend to other global pins,
> such as reset?
>
> Would the problem appear in a post-PAR gate level simulation of the
> design?
>
> Is one of the signals clocked, and the other strictly combinatorial?
>
> Brian

yes all global pins like reset, global tristate are excluded

the problem would appear in simulation given __proper__ stimuly _and_
technology dependant simulaton libraries
but I am not sure if simulation libraries from any FPGA vendor are
accurate enough for the problem to become visible

the issue would appear if
only 2 outputs LED1 and LED2 are used
no clocks connected to any FPGA IOB (only blink_one_second signal
toggles)

Antti



Article: 125112
Subject: Re: FPGA quiz: what can be wrong
From: Antti <Antti.Lukats@googlemail.com>
Date: Tue, 16 Oct 2007 12:29:41 -0000
Links: << >>  << T >>  << A >>
On 16 Okt., 14:13, MikeShepherd...@btinternet.com wrote:
> Don't you people have anything better to do?  We all come across
> puzzling and time-consuming problems where we've made what seems to be
> a reasonable assumption but which turns out to be false.  The lesson
> is sobering, but the sterile chase after another's problem is little
> more than self-indulgence.
>
> As Gauss put it:(when others tempted him to become interested in
> Fermat's conjecture):  "I confess that Fermat's Theorem as an isolated
> proposition has very little interest for me, because I could easily
> lay down a multitude of such propositions, which one could neither
> prove nor dispose of".

Sorry Mike

I did not expect so many replies ;)
well, I th=EDnk there is something to learn in this, and hope you agree
when the solution is revealed.

OK, some more hints: the "perfect answer" to the original quiz would
be one single 6 letter word.

I do not expect someone to be guess it, but the possibilities of
possible cause are getting low, the answer will soon be known so or
so.

Antti


From laurent.pinchart@skynet.be Tue Oct 16 05:46:26 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: <4714b2a2$0$22318$ba620e4c@news.skynet.be>
From: Laurent Pinchart <laurent.pinchart@skynet.be>
Subject: Re: FPGA quiz: what can be wrong
Newsgroups: comp.arch.fpga
Date: Tue, 16 Oct 2007 14:46:26 +0200
References: <1192462938.206319.120810@i13g2000prf.googlegroups.com>
User-Agent: KNode/0.10.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
Lines: 35
Organization: -= Belgacom Usenet Service =-
NNTP-Posting-Host: 71385f48.news.skynet.be
X-Trace: 1192538786 news.skynet.be 22318 194.78.198.49:51832
X-Complaints-To: usenet-abuse@skynet.be
Xref: prodigy.net comp.arch.fpga:137100

Antti wrote:

> 
> vhdl code
> 
> LED1 <= some_signal;
> LED2 <= blink_one_second;
> 
> the LED1,2 are connected to LED's
> blink_one_second is simple wire that drives LED2 and nothing else.
> 
> now the code works in real FPGA with following behaviour:
> 
> when some_signal = 0, then LED2 blinks.
> when some_signal = 1, then both LEDs blink as full sync to each other.
> 
> what can cause this?
> 
> some wrong answers: faulty FPGA fabric, bad PCB, bad power supply.
> 
> eh, the solution to the problem was weird. but it does exist. sure I
> assumed FPGA fabric faulty first as I had overstressed the FPGA with
> 5V supply, and reversed 3.3V supply too. but FPGA is alive and fully
> working, yet the weird behaviour exist. and this is actually correct
> behaviour in the particular case.
> 
> I wonder if somebody is able to quess the answer to the issue. happy
> thinking!
> 
> Antti

Would the source and post p&r simulation exhibit the same behavior ?

Laurent Pinchart


Article: 125113
Subject: Re: FPGA quiz2: spartan3A return Virtex JTAGID. Also prizes for quiz1 and quiz2
From: naughty.zeut@gmail.com
Date: Tue, 16 Oct 2007 05:59:34 -0700
Links: << >>  << T >>  << A >>
On Oct 16, 6:45 am, Antti <Antti.Luk...@googlemail.com> wrote:
> On 16 Okt., 13:42, Laurent Pinchart <laurent.pinch...@skynet.be>
> wrote:
>
>
>
> >  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
>
> > > Antti
> > > (sorry for posting from different account, google goups asserted temp.
> > > block on my primary account)
>
> > Could the family and device ID be stored as some kind of fuses that got
> > burnt when VCCINT was raised to 1.8V ?
>
> > Laurent Pinchart- Zitierten Text ausblenden -
>
> > - Zitierten Text anzeigen -
>
> it was my first guess too, but no this is not the case
>
> Antti

Is this the Spartan 3A that was originally going to be a Virtex family
chip, then they rebranded it but did not change the ID?

S Woods


Article: 125114
Subject: Re: FPGA quiz: what can be wrong
From: Antti <Antti.Lukats@googlemail.com>
Date: Tue, 16 Oct 2007 13:01:43 -0000
Links: << >>  << T >>  << A >>
On 16 Okt., 14:46, Laurent Pinchart <laurent.pinch...@skynet.be>
wrote:
> Antti wrote:
>
> > vhdl code
>
> > LED1 <= some_signal;
> > LED2 <= blink_one_second;
>
> > the LED1,2 are connected to LED's
> > blink_one_second is simple wire that drives LED2 and nothing else.
>
> > now the code works in real FPGA with following behaviour:
>
> > when some_signal = 0, then LED2 blinks.
> > when some_signal = 1, then both LEDs blink as full sync to each other.
>
> > what can cause this?
>
> > some wrong answers: faulty FPGA fabric, bad PCB, bad power supply.
>
> > eh, the solution to the problem was weird. but it does exist. sure I
> > assumed FPGA fabric faulty first as I had overstressed the FPGA with
> > 5V supply, and reversed 3.3V supply too. but FPGA is alive and fully
> > working, yet the weird behaviour exist. and this is actually correct
> > behaviour in the particular case.
>
> > I wonder if somebody is able to quess the answer to the issue. happy
> > thinking!
>
> > Antti
>
> Would the source and post p&r simulation exhibit the same behavior ?
>
> Laurent Pinchart- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

I must think more to answer properly ;)

a full simulation of the code with proper stimuly would simulate the
same before and after P&R given the __needed__ accuracy of the
technology dependand simulation libraries.

but, as said I do not know if the current FPGA vendor simulation
libraries are accurate for the issue become visible. It is likely that
the behaviour as observed can not be seen in simulation (no matter
proper stimuli). if it comes visible in sims then P&R step would make
no difference to the simulation behaviour as FPGA fabric delays, have
NO influence on the behaviour at all

Antti







From laurent.pinchart@skynet.be Tue Oct 16 06:02:43 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!feeder2.ecngs.de!ecngs!feeder.ecngs.de!feed1.news.be.easynet.net!news.skynet.be!195.238.0.222.MISMATCH!newsspl501.isp.belgacom.be!tjb!not-for-mail
Message-Id: <4714b674$0$22320$ba620e4c@news.skynet.be>
From: Laurent Pinchart <laurent.pinchart@skynet.be>
Subject: Re: FPGA quiz2: spartan3A return Virtex JTAGID. Also prizes for quiz1 and quiz2
Newsgroups: comp.arch.fpga
Date: Tue, 16 Oct 2007 15:02:43 +0200
References: <1192516229.210765.81880@i38g2000prf.googlegroups.com> <47146d74$0$22318$ba620e4c@news.skynet.be> <1192521253.554269.233090@k35g2000prh.googlegroups.com> <471473a0$0$22304$ba620e4c@news.skynet.be> <1192526478.079175.263900@k35g2000prh.googlegroups.com> <4714a3af$0$22307$ba620e4c@news.skynet.be> <1192535103.185944.294970@q5g2000prf.googlegroups.com>
User-Agent: KNode/0.10.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
Lines: 62
Organization: -= Belgacom Usenet Service =-
NNTP-Posting-Host: 845cacbd.news.skynet.be
X-Trace: 1192539764 news.skynet.be 22320 194.78.198.49:53803
X-Complaints-To: usenet-abuse@skynet.be
Xref: prodigy.net comp.arch.fpga:137103

Antti wrote:

> On 16 Okt., 13:42, Laurent Pinchart <laurent.pinch...@skynet.be>
> wrote:
>>  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
>>
>> > Antti
>> > (sorry for posting from different account, google goups asserted temp.
>> > block on my primary account)
>>
>> Could the family and device ID be stored as some kind of fuses that got
>> burnt when VCCINT was raised to 1.8V ?
>>
>> Laurent Pinchart- Zitierten Text ausblenden -
>>
>> - Zitierten Text anzeigen -
> 
> it was my first guess too, but no this is not the case
> 
> Antti

Did the JTAGID change after you applied VCCINT=1.8V or was it already
defective before ?

Laurent Pinchart


From laurent.pinchart@skynet.be Tue Oct 16 06:06:36 2007
Path: newssvr25.news.prodigy.net!newsdbm05.news.prodigy.net!newsdst01.news.prodigy.net!prodigy.com!newscon04.news.prodigy.net!prodigy.net!newshub.sdsu.edu!feeder.news-service.com!news-out1.kabelfoon.nl!newsfeed.kabelfoon.nl!bandi.nntp.kabelfoon.nl!kramikske.telenet-ops.be!nntp.telenet.be!feed1.news.be.easynet.net!news.skynet.be!195.238.0.222.MISMATCH!newsspl501.isp.belgacom.be!tjb!not-for-mail
Message-Id: <4714b75c$0$22320$ba620e4c@news.skynet.be>
From: Laurent Pinchart <laurent.pinchart@skynet.be>
Subject: Re: FPGA quiz: what can be wrong
Newsgroups: comp.arch.fpga
Date: Tue, 16 Oct 2007 15:06:36 +0200
References: <1192462938.206319.120810@i13g2000prf.googlegroups.com> <4714b2a2$0$22318$ba620e4c@news.skynet.be> <1192539703.614577.111460@e9g2000prf.googlegroups.com>
User-Agent: KNode/0.10.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
Lines: 60
Organization: -= Belgacom Usenet Service =-
NNTP-Posting-Host: 845cacbd.news.skynet.be
X-Trace: 1192539996 news.skynet.be 22320 194.78.198.49:53803
X-Complaints-To: usenet-abuse@skynet.be
Xref: prodigy.net comp.arch.fpga:137104

Antti wrote:

> On 16 Okt., 14:46, Laurent Pinchart <laurent.pinch...@skynet.be>
> wrote:
>> Antti wrote:
>>
>> > vhdl code
>>
>> > LED1 <= some_signal;
>> > LED2 <= blink_one_second;
>>
>> > the LED1,2 are connected to LED's
>> > blink_one_second is simple wire that drives LED2 and nothing else.
>>
>> > now the code works in real FPGA with following behaviour:
>>
>> > when some_signal = 0, then LED2 blinks.
>> > when some_signal = 1, then both LEDs blink as full sync to each other.
>>
>> > what can cause this?
>>
>> > some wrong answers: faulty FPGA fabric, bad PCB, bad power supply.
>>
>> > eh, the solution to the problem was weird. but it does exist. sure I
>> > assumed FPGA fabric faulty first as I had overstressed the FPGA with
>> > 5V supply, and reversed 3.3V supply too. but FPGA is alive and fully
>> > working, yet the weird behaviour exist. and this is actually correct
>> > behaviour in the particular case.
>>
>> > I wonder if somebody is able to quess the answer to the issue. happy
>> > thinking!
>>
>> > Antti
>>
>> Would the source and post p&r simulation exhibit the same behavior ?
>>
>> Laurent Pinchart- Zitierten Text ausblenden -
>>
>> - Zitierten Text anzeigen -
> 
> I must think more to answer properly ;)
> 
> a full simulation of the code with proper stimuly would simulate the
> same before and after P&R given the __needed__ accuracy of the
> technology dependand simulation libraries.
> 
> but, as said I do not know if the current FPGA vendor simulation
> libraries are accurate for the issue become visible. It is likely that
> the behaviour as observed can not be seen in simulation (no matter
> proper stimuli). if it comes visible in sims then P&R step would make
> no difference to the simulation behaviour as FPGA fabric delays, have
> NO influence on the behaviour at all

So the post-map and post-p&r simulation would both exhibit the issue given
proper vendor libraries, but source simulation (before synthesis) wouldn't,
as it doesn't involve vendor libraries. Or does your design use vendor
components in addition to pure VHDL code ?

Laurent Pinchart


Article: 125115
Subject: Re: FPGA quiz: what can be wrong
From: Antti <Antti.Lukats@googlemail.com>
Date: Tue, 16 Oct 2007 13:11:10 -0000
Links: << >>  << T >>  << A >>
On 16 Okt., 14:46, Laurent Pinchart <laurent.pinch...@skynet.be>
wrote:
> Antti wrote:
>
> > vhdl code
>
> > LED1 <= some_signal;
> > LED2 <= blink_one_second;
>
> > the LED1,2 are connected to LED's
> > blink_one_second is simple wire that drives LED2 and nothing else.
>
> > now the code works in real FPGA with following behaviour:
>
> > when some_signal = 0, then LED2 blinks.
> > when some_signal = 1, then both LEDs blink as full sync to each other.
>
> > what can cause this?
>
> > some wrong answers: faulty FPGA fabric, bad PCB, bad power supply.
>
> > eh, the solution to the problem was weird. but it does exist. sure I
> > assumed FPGA fabric faulty first as I had overstressed the FPGA with
> > 5V supply, and reversed 3.3V supply too. but FPGA is alive and fully
> > working, yet the weird behaviour exist. and this is actually correct
> > behaviour in the particular case.
>
> > I wonder if somebody is able to quess the answer to the issue. happy
> > thinking!
>
> > Antti
>
> Would the source and post p&r simulation exhibit the same behavior ?
>
> Laurent Pinchart- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

I must think more to answer properly ;)

a full simulation of the code with proper stimuly would simulate the
same before and after P&R given the __needed__ accuracy of the
technology dependand simulation libraries.

but, as said I do not know if the current FPGA vendor simulation
libraries are accurate for the issue become visible. It is likely that
the behaviour as observed can not be seen in simulation (no matter
proper stimuli). if it comes visible in sims then P&R step would make
no difference to the simulation behaviour as FPGA fabric delays, have
NO influence on the behaviour at all

Antti







Article: 125116
Subject: Re: Xilinx timing constraints incorrect?
From: paragon.john@gmail.com
Date: Tue, 16 Oct 2007 13:36:05 -0000
Links: << >>  << T >>  << A >>
On Oct 15, 7:31 pm, Duane Clark <junkm...@junkmail.com> wrote:
> paragon.j...@gmail.com wrote:
> > Hello all,
>
> > I am working on a design for a Xilinx V2P50 and I am trying to
> > diagnose possible timing issues because the hardware performance of my
> > design does not appear to match simulation.
>
> > I have run the design through Timing Analyzer (ISE 8.2) and notice a
> > huge number of unconstrained paths of the following format
>
> > "FROM *clk_pad* TO *register*"
>
> > where *clk_pad* is a clock pad in the design, and *register* is a
> > register in the design that is clocked...
>
> I think those only occur when a local net is used somewhere in the clock
> path. Are you using a gated clock? Is the clock pad using a pin other
> than the one with a direct connection to a global clock buffer?
>
> Why don't you post one of the unconstrained paths. That is, the part
> that should look something like:
>
> [removed for readability]

Thanks for your response.

I do have a gated clock of the following form:  GATED_CLOCK <= ENABLE
and not GATED_CLOCK.  This signal is not used to clock any flip flops
in the FPGA, it is immediately connected to an output buffer.
Unfortunately, this signal is needed.  Maybe there are some
constraints I need to put on this signal that I am unaware of?

Here is an example unconstrained path:

--------------------------------------------------------------------------------
Delay:                  1.435ns (data path)
  Source:               Clk_n (PAD)
  Destination:          [Flip-flop in hierarchy] (FF)
  Data Path Delay:      1.435ns (Levels of Logic = 4)
  Constraint Improvement Wizard
  Data Path: Clk_n to [Flip-flop in hierarchy]
    Delay type         Delay(ns)  Logical Resource(s)
    ----------------------------  -------------------
    Tiopp                 0.276   Clk_n
    net (fanout=1)        0.000   U_AD_IF/IBUFG_Clk/SLAVEBUF.DIFFIN
    Tdiffin               0.812   U_AD_IF/IBUFG_Clk/IBUFDS
    net (fanout=1)        0.452   U_AD_IF/BUF_Clk
    Tdcmino              -2.529   U_AD_IF/DCM_Clk
    net (fanout=1)        0.823   U_AD_IF/DCM_Clk_0
    Tgi0o                 0.050   U_AD_IF/BUFG_Clk
    net (fanout=20886)   1.551   AD_Clk
    ----------------------------  ---------------------------
    Total                 1.435ns (-1.391ns logic, 2.826ns route)

Thanks!


Article: 125117
Subject: Re: FPGA to FPGA Bus
From: "RCIngham" <robert.ingham@gmail.com>
Date: Tue, 16 Oct 2007 08:36:11 -0500
Links: << >>  << T >>  << A >>
>
>Hi
>
>I would like to connect 3 FPGA devices together using a 32-bit bus. Also
I
>would like all 3 to be masters on the bus. Is there any standard bus out
>there that would do this rather than me coming up with my own idea. 
>
>Jon
>
PCI would fit the bill, especially if you leverage open-source RTL.



Article: 125118
Subject: Re: FPGA quiz2: spartan3A return Virtex JTAGID. Also prizes for quiz1 and quiz2
From: avrbasic@hotmail.com
Date: Tue, 16 Oct 2007 13:39:22 -0000
Links: << >>  << T >>  << A >>
On 16 Okt., 15:02, Laurent Pinchart <laurent.pinch...@skynet.be>
wrote:
> Antti wrote:
> > On 16 Okt., 13:42, Laurent Pinchart <laurent.pinch...@skynet.be>
> > wrote:
> >>  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
>
> >> > Antti
> >> > (sorry for posting from different account, google goups asserted temp.
> >> > block on my primary account)
>
> >> Could the family and device ID be stored as some kind of fuses that got
> >> burnt when VCCINT was raised to 1.8V ?
>
> >> Laurent Pinchart- Zitierten Text ausblenden -
>
> >> - Zitierten Text anzeigen -
>
> > it was my first guess too, but no this is not the case
>
> > Antti
>
> Did the JTAGID change after you applied VCCINT=1.8V or was it already
> defective before ?
>
> Laurent Pinchart- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

I did not observe the wrong ID before.
I did some rework on the PCB, the VCCINT regulator VCCADJ did fell
off, and i was suddenly measuring 1.8V
after fixing the supply and completing my PCB rework, the ID was
wrong.

the problem has been fixed, and the same FPGA now works fully ok again
and returns correct ID too.

Antti






Article: 125119
Subject: Re: Xilinx timing constraints incorrect?
From: paragon.john@gmail.com
Date: Tue, 16 Oct 2007 13:41:48 -0000
Links: << >>  << T >>  << A >>
On Oct 16, 9:36 am, paragon.j...@gmail.com wrote:
> On Oct 15, 7:31 pm, Duane Clark <junkm...@junkmail.com> wrote:
>
>
>
> > paragon.j...@gmail.com wrote:
> > > Hello all,
>
> > > I am working on a design for a Xilinx V2P50 and I am trying to
> > > diagnose possible timing issues because the hardware performance of my
> > > design does not appear to match simulation.
>
> > > I have run the design through Timing Analyzer (ISE 8.2) and notice a
> > > huge number of unconstrained paths of the following format
>
> > > "FROM *clk_pad* TO *register*"
>
> > > where *clk_pad* is a clock pad in the design, and *register* is a
> > > register in the design that is clocked...
>
> > I think those only occur when a local net is used somewhere in the clock
> > path. Are you using a gated clock? Is the clock pad using a pin other
> > than the one with a direct connection to a global clock buffer?
>
> > Why don't you post one of the unconstrained paths. That is, the part
> > that should look something like:
>
> > [removed for readability]
>
> Thanks for your response.
>
> I do have a gated clock of the following form:  GATED_CLOCK <= ENABLE
> and not CLOCK.  This signal is not used to clock any flip flops
> in the FPGA, it is immediately connected to an output buffer.
> Unfortunately, this signal is needed.  Maybe there are some
> constraints I need to put on this signal that I am unaware of?
>
> Here is an example unconstrained path:
>
> --------------------------------------------------------------------------------
> Delay:                  1.435ns (data path)
>   Source:               Clk_n (PAD)
>   Destination:          [Flip-flop in hierarchy] (FF)
>   Data Path Delay:      1.435ns (Levels of Logic = 4)
>   Constraint Improvement Wizard
>   Data Path: Clk_n to [Flip-flop in hierarchy]
>     Delay type         Delay(ns)  Logical Resource(s)
>     ----------------------------  -------------------
>     Tiopp                 0.276   Clk_n
>     net (fanout=1)        0.000   U_AD_IF/IBUFG_Clk/SLAVEBUF.DIFFIN
>     Tdiffin               0.812   U_AD_IF/IBUFG_Clk/IBUFDS
>     net (fanout=1)        0.452   U_AD_IF/BUF_Clk
>     Tdcmino              -2.529   U_AD_IF/DCM_Clk
>     net (fanout=1)        0.823   U_AD_IF/DCM_Clk_0
>     Tgi0o                 0.050   U_AD_IF/BUFG_Clk
>     net (fanout=20886)   1.551   AD_Clk
>     ----------------------------  ---------------------------
>     Total                 1.435ns (-1.391ns logic, 2.826ns route)
>
> Thanks!

Correction to the above post:  The gated clock should be
GATED_CLOCK <= ENABLE and not CLOCK
Note that this clock is a divided by 4 clock of the clock in the above
constraint, generated by the DCM.


Article: 125120
Subject: Re: FPGA quiz: what can be wrong
From: avrbasic@hotmail.com
Date: Tue, 16 Oct 2007 13:52:10 -0000
Links: << >>  << T >>  << A >>
On 16 Okt., 15:06, Laurent Pinchart <laurent.pinch...@skynet.be>
wrote:
> Antti wrote:
> > On 16 Okt., 14:46, Laurent Pinchart <laurent.pinch...@skynet.be>
> > wrote:
> >> Antti wrote:
>
> >> > vhdl code
>
> >> > LED1 <= some_signal;
> >> > LED2 <= blink_one_second;
>
> >> > the LED1,2 are connected to LED's
> >> > blink_one_second is simple wire that drives LED2 and nothing else.
>
> >> > now the code works in real FPGA with following behaviour:
>
> >> > when some_signal = 0, then LED2 blinks.
> >> > when some_signal = 1, then both LEDs blink as full sync to each other.
>
> >> > what can cause this?
>
> >> > some wrong answers: faulty FPGA fabric, bad PCB, bad power supply.
>
> >> > eh, the solution to the problem was weird. but it does exist. sure I
> >> > assumed FPGA fabric faulty first as I had overstressed the FPGA with
> >> > 5V supply, and reversed 3.3V supply too. but FPGA is alive and fully
> >> > working, yet the weird behaviour exist. and this is actually correct
> >> > behaviour in the particular case.
>
> >> > I wonder if somebody is able to quess the answer to the issue. happy
> >> > thinking!
>
> >> > Antti
>
> >> Would the source and post p&r simulation exhibit the same behavior ?
>
> >> Laurent Pinchart- Zitierten Text ausblenden -
>
> >> - Zitierten Text anzeigen -
>
> > I must think more to answer properly ;)
>
> > a full simulation of the code with proper stimuly would simulate the
> > same before and after P&R given the __needed__ accuracy of the
> > technology dependand simulation libraries.
>
> > but, as said I do not know if the current FPGA vendor simulation
> > libraries are accurate for the issue become visible. It is likely that
> > the behaviour as observed can not be seen in simulation (no matter
> > proper stimuli). if it comes visible in sims then P&R step would make
> > no difference to the simulation behaviour as FPGA fabric delays, have
> > NO influence on the behaviour at all
>
> So the post-map and post-p&r simulation would both exhibit the issue given
> proper vendor libraries, but source simulation (before synthesis) wouldn't,
> as it doesn't involve vendor libraries. Or does your design use vendor
> components in addition to pure VHDL code ?
>
> Laurent Pinchart- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

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.

well the FPGA device in question is not a Xilinx device anyway.

Antti


Article: 125121
Subject: Re: Graphical VHDL Viewer ?
From: Patrick Dubois <prdubois@gmail.com>
Date: Tue, 16 Oct 2007 14:01:17 -0000
Links: << >>  << T >>  << A >>
On 12 oct, 04:32, "St=E9phane Julhes" <sjul...@adeneo.adetelgroup.com>
wrote:
> Hi all,
>
> Does anyone know a free/simple software that would use vhdl files to prod=
uce
> a graphical view ?
> The goal is to have a easier and faster read of the architecture of a vhdl
> file and its components.
>
> Thanks.
>
> St=E9phane.

It will not help in your current situation, but I would recommend
Active-HDL for your future designs (not free unfortunately). What we
do is that we do the design in a graphical manner with boxes connected
to each other in a schematic editor. Then each box is a VHDL file or
another level of schematic. That way it us MUCH easier to understand
the design than to try to understand the VHDL netlist. Each schematic
is converted automatically to a VHDL file, so it's always possible to
go back to a simple VHDL netlist if desired.

Patrick


Article: 125122
Subject: Re: FPGA quiz: what can be wrong
From: "MM" <mbmsv@yahoo.com>
Date: Tue, 16 Oct 2007 10:15:40 -0400
Links: << >>  << T >>  << A >>
"Antti" <Antti.Lukats@googlemail.com> wrote in message 
news:1192513850.557192.144210@q5g2000prf.googlegroups.com...
>
> FPGA_pin - RESISTOR - LED - GND
>
> but as said the LED connection really had nothing todo with the issue

OK, what's the resistor's value, what's the LED's forward voltage, which 
buffer type is used (current limiting?), what's the VCC?

Unfortunately, I'll be away from my computer for quite a few hours, so I am 
probably out of this game...


/Mikhail 



Article: 125123
Subject: Re: FPGA quiz2: spartan3A return Virtex JTAGID. Also prizes for quiz1 and quiz2
From: avrbasic@hotmail.com
Date: 16 Oct 2007 07:28:07 -0700
Links: << >>  << T >>  << A >>
On 16 Okt., 14:59, naughty.z...@gmail.com wrote:
> On Oct 16, 6:45 am, Antti <Antti.Luk...@googlemail.com> wrote:
>
>
>
>
>
> > On 16 Okt., 13:42, Laurent Pinchart <laurent.pinch...@skynet.be>
> > wrote:
>
> > >  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
>
> > > > Antti
> > > > (sorry for posting from different account, google goups asserted temp.
> > > > block on my primary account)
>
> > > Could the family and device ID be stored as some kind of fuses that got
> > > burnt when VCCINT was raised to 1.8V ?
>
> > > Laurent Pinchart- Zitierten Text ausblenden -
>
> > > - Zitierten Text anzeigen -
>
> > it was my first guess too, but no this is not the case
>
> > Antti
>
> Is this the Spartan 3A that was originally going to be a Virtex family
> chip, then they rebranded it but did not change the ID?
>
> S Woods- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

WAU, thats good guess!!

well on the plastic housing there is part of the text that has been
laser-erased after chip marking for some reason

but no, this is not the case for the wrong ID readback

Antti


Article: 125124
Subject: Re: FPGA quiz: what can be wrong
From: cs_posting@hotmail.com
Date: Tue, 16 Oct 2007 08:04:25 -0700
Links: << >>  << T >>  << A >>
On Oct 16, 6:02 am, avrba...@hotmail.com wrote:

> it is some FPGA feature that causes it. the reason it happens (in the
> case described) is bound to one specific FPGA device family, but
> similar case is also thinkable and repeatable on other family and
> vendor FPGA with some minor changes

Something to do with the IO protection diodes?

Maybe even powering the device or at least an IO bank through the IO
pins and those diodes, rather than through the supply pins?






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