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 130825

Article: 130825
Subject: Re: counterfeit Xilinx ?
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 2 Apr 2008 14:26:19 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 2, 3:08=A0pm, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> craig.tay...@xilinx.com wrote:
> > In many cases Xilinx will not be
> > able to assist you in determining if those suspect devices are
> > legitimate or usable.
>
> Hmmm - so these are no counterfeit at all (in the literal sense)
>
> but relabeled devices ? - Maybe Xilinx die from Easypath,
> or do Xilinx have 'creepage' issues on their test rejects ?
>
> -jg
Jim, this is all idle speculation. At least, Jon was desrcribing his
dubious source openly.
When it comes to things that you cannot easily evaluate (like FPGAs,
microprocessors, food, medicine etc) you do not want to buy them at
the flea market.
The fact that the parts look like the real thing is incidental.
I was wrong in offering help (but nobody in Xilinx has chewed me out
for it. We are a friendly company,) but I now realize the mistake).
Peter Alfke

Article: 130826
Subject: Re: counterfeit Xilinx ?
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Thu, 03 Apr 2008 10:08:04 +1200
Links: << >>  << T >>  << A >>
craig.taylor@xilinx.com wrote:
> In many cases Xilinx will not be
> able to assist you in determining if those suspect devices are
> legitimate or usable.

Hmmm - so these are no counterfeit at all (in the literal sense)

but relabeled devices ? - Maybe Xilinx die from Easypath,
or do Xilinx have 'creepage' issues on their test rejects ?

-jg


Article: 130827
Subject: Re: async clk input, clock glitches
From: Jon Elson <elson@wustl.edu>
Date: Wed, 02 Apr 2008 16:50:48 -0600
Links: << >>  << T >>  << A >>


Antti wrote:

> failing circuit
> 
> ASIC outpu t> 15mm trace > connector > 5mm trace > 27 ohm > 3mm trace
> FPGA input >
> 
>>F-F strobed with 50mhz > global clock buffer > 2 bit counter
> 
> 
> now, this 2 bit counter sees
> * double clock from asic in about 1:10M pulses
> * missing clock from asic in about 1:100m pulses
> 
> the asic clock is know to be perfect many other devices can receive it
> and have 0 error rate (have not seen error ever!)
> the 50mhz clock signal quality, well it doesn matter, as whatever
> could be wrong, it could not explain the double and missing pulse
> counts ?
> 
> using PLL on 4mhz is not an option as it is not free running clock but
> byte strobe with 4mhz pulses
OK, how long does the data stay available after the strobe?  If greater 
than 20 ns,
you can register the 4 MHz clock and then clock the data bits by 
enabling the register.  If the data has to be clocked from the 4 MHz, 
then you can use the 4 MHz as a clock to the register, and set a bit, 
too.  That bit tells another register to copy the data from the register 
that is clocked by the 4 MHz clock.  So, you crossing the clock boundary 
at the already latched parallel data, not the clock itself.  You can put 
whatever filtering is needed in to qualify the 4 MHz clock edges, if 
needed, like reject any clock edge within 40 ns of one that you accepted.

Jon


Article: 130828
Subject: Re: async clk input, clock glitches
From: Jon Elson <elson@wustl.edu>
Date: Wed, 02 Apr 2008 16:57:39 -0600
Links: << >>  << T >>  << A >>


Antti wrote:

> after that I did remove some of the logic from FPGA (not related to
> the "counter") freeing some 30% of the FPGA, dropping FPGA utilization
> from 82 to 54%
> 
> and the error rate dropped
> * double strobes: 1:500M
> * missing strobes: 0, - not happened yet, still running long term test
> 
Ugh!  Analog FPGAs!  Something I don't want to hear about!!!!  You may 
want to look at these clocks (both of them) with a fast analog scope or 
a really good digital one.  Even if the 4 MHz clock is extremely clean 
with great rise/fall times, if the 50 MHz is noisy or has slow edges, 
you'd hardly know the difference.  What I'm trying to say is jitter or 
double clocking of the 50 MHz clock could foul up the relationship 
between it and the 4 MHz, although I guess it would have to be truly 
horrible to do that, and the symptoms would undoubtedly show up 
somewhere else, too.  Is the 50 MHz processed by PLLs?  Noisy power 
could affect the locking of the PLL.  Good luck, but I doubt you are
going to really nail this without serious scope probing.

Jon


Article: 130829
Subject: Re: async clk input, clock glitches
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 2 Apr 2008 16:49:04 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 2, 3:57=A0pm, Jon Elson <el...@wustl.edu> wrote:
> Antti wrote:
> > after that I did remove some of the logic from FPGA (not related to
> > the "counter") freeing some 30% of the FPGA, dropping FPGA utilization
> > from 82 to 54%
>
> > and the error rate dropped
> > * double strobes: 1:500M
> > * missing strobes: 0, - not happened yet, still running long term test
>
> Ugh! =A0Analog FPGAs! =A0Something I don't want to hear about!!!! =A0You m=
ay
> want to look at these clocks (both of them) with a fast analog scope or
> a really good digital one. =A0Even if the 4 MHz clock is extremely clean
> with great rise/fall times, if the 50 MHz is noisy or has slow edges,
> you'd hardly know the difference. =A0What I'm trying to say is jitter or
> double clocking of the 50 MHz clock could foul up the relationship
> between it and the 4 MHz, although I guess it would have to be truly
> horrible to do that, and the symptoms would undoubtedly show up
> somewhere else, too. =A0Is the 50 MHz processed by PLLs? =A0Noisy power
> could affect the locking of the PLL. =A0Good luck, but I doubt you are
> going to really nail this without serious scope probing.
>
> Jon

Well, if you worry about double-clocking, there are simple bad-aid
fixes that let you live with the double edges: click on
http://www.nalanda.nitc.ac.in/industry/appnotes/xilinx/documents/xcel...
which shows two different ways to avoid the effect of double-edges on
a clock.
I wrote that long ago, and published it in Xilinx XCell magazine #34
Peter Alfke (repeat of my posting of several days ago)

Article: 130830
Subject: Re: counterfeit Xilinx ?
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Thu, 03 Apr 2008 11:59:19 +1200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> On Apr 2, 3:08 pm, Jim Granville <no.s...@designtools.maps.co.nz>
> wrote:
> 
>>craig.tay...@xilinx.com wrote:
>>
>>>In many cases Xilinx will not be
>>>able to assist you in determining if those suspect devices are
>>>legitimate or usable.
>>
>>Hmmm - so these are no counterfeit at all (in the literal sense)
>>
>>but relabeled devices ? - Maybe Xilinx die from Easypath,
>>or do Xilinx have 'creepage' issues on their test rejects ?
>>
>>-jg
> 
> Jim, this is all idle speculation. At least, Jon was desrcribing his
> dubious source openly.
> When it comes to things that you cannot easily evaluate (like FPGAs,
> microprocessors, food, medicine etc) you do not want to buy them at
> the flea market.

Agreed

> The fact that the parts look like the real thing is incidental.

Yes and no. If it were my company, I'd be interested in just
HOW the parts got to be there.

Do I need to tighten up the Testers, or Fabs, or do I need
to laser mark EasyPath devices ? - or are they
someone elses pulls, nicely refurbished
(possible, but rather unlikely, due to erratic volumes)

Grey market devices are usually 'easy dollars',
so a speed-grade hike is one easy action.
Intel has struggled with this.

Xilinx's call - I guess this must be in the noise floor for them.

-jg




Article: 130831
Subject: Re: async clk input, clock glitches
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 2 Apr 2008 17:10:43 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 2, 4:49=A0pm, Peter Alfke <pe...@xilinx.com> wrote:
> On Apr 2, 3:57=A0pm, Jon Elson <el...@wustl.edu> wrote:
>
>
>
> > Antti wrote:
> > > after that I did remove some of the logic from FPGA (not related to
> > > the "counter") freeing some 30% of the FPGA, dropping FPGA utilization=

> > > from 82 to 54%
>
> > > and the error rate dropped
> > > * double strobes: 1:500M
> > > * missing strobes: 0, - not happened yet, still running long term test=

>
> > Ugh! =A0Analog FPGAs! =A0Something I don't want to hear about!!!! =A0You=
 may
> > want to look at these clocks (both of them) with a fast analog scope or
> > a really good digital one. =A0Even if the 4 MHz clock is extremely clean=

> > with great rise/fall times, if the 50 MHz is noisy or has slow edges,
> > you'd hardly know the difference. =A0What I'm trying to say is jitter or=

> > double clocking of the 50 MHz clock could foul up the relationship
> > between it and the 4 MHz, although I guess it would have to be truly
> > horrible to do that, and the symptoms would undoubtedly show up
> > somewhere else, too. =A0Is the 50 MHz processed by PLLs? =A0Noisy power
> > could affect the locking of the PLL. =A0Good luck, but I doubt you are
> > going to really nail this without serious scope probing.
>
> > Jon
>
> Well, if you worry about double-clocking, there are simple bad-aid
> fixes that let you live with the double edges: click onhttp://www.nalanda.=
nitc.ac.in/industry/appnotes/xilinx/documents/xcel...
> which shows two different ways to avoid the effect of double-edges on
> a clock.
> I wrote that long ago, and published it in Xilinx XCell magazine #34
> Peter Alfke (repeat of my posting of several days ago)

sloppy typing: I meant "band-aid fixes", since some purists insist
that it is bad practice to live with such a problem. But I prefer a
band-aid to the alternative of spreading blood all over the place or
even bleeding to death.
Peter

Article: 130832
Subject: Re: async clk input, clock glitches
From: Torsten Landschoff <t.landschoff@gmx.de>
Date: Thu, 3 Apr 2008 00:33:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi Peter,

On 3 Apr., 01:49, Peter Alfke <pe...@xilinx.com> wrote:

> Well, if you worry about double-clocking, there are simple bad-aid
> fixes that let you live with the double edges: click onhttp://www.nalanda.nitc.ac.in/industry/appnotes/xilinx/documents/xcel...
> which shows two different ways to avoid the effect of double-edges on
> a clock.
> I wrote that long ago, and published it in Xilinx XCell magazine #34

I was curious about that article. I don't currently have any related
problem but learning these tricks might help me down the road.

Unfortunately the link you posted is dead. I tried to dig it up from
the xcell archives on xilinx.com, but the last issue available is #48.
It would be nice to have the older issues available as well,
especially for newcomers who can still learn some basic/historical
stuff from that.

Do you know another archive?

Greetings, Torsten

Article: 130833
Subject: Re: async clk input, clock glitches
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Thu, 3 Apr 2008 09:12:02 +0100
Links: << >>  << T >>  << A >>
> I was curious about that article. I don't currently have any related
> problem but learning these tricks might help me down the road.
>
> Unfortunately the link you posted is dead. I tried to dig it up from
> the xcell archives on xilinx.com, but the last issue available is #48.
> It would be nice to have the older issues available as well,
> especially for newcomers who can still learn some basic/historical
> stuff from that.


Here's the full link Peter posted a couple of days ago...

http://www.nalanda.nitc.ac.in/industry/appnotes/xilinx/documents/xcell/xl34/xl34_54.pdf



Nial 



Article: 130834
Subject: EDK 10.1 first impressions
From: Antti <Antti.Lukats@googlemail.com>
Date: Thu, 3 Apr 2008 03:10:29 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi

here it goes: I got last week new notebook that is faster then the
desktop, so I installed 10.x tools there.

And I had a small task to verify something with ML505, so I fire up
EDK 10.1 open the ML505 reference design, and within 3 minutes EDK
self-terminates.

So TTFFF (time to first fatal failure) 3 minutes.

Ok, this way my fault i opened the XMP project from compressed folder,
how foolish from me. But even so EDK should not self-terminate on such
event IMHO.

Now I open the project from normal folder, after project rev-up the
file isnt opened.

NEED MANUAL fix!

I have been told that there are many people who have tested the 10.1
before release, i would have assumed the Xilinx DEFAULT MAIN refernece
design for ML505 was tested as one of the first test cases, but no it
wasnt.

Ok, I fix manually the MHS file.

After some hour of implementation run the project fails with some IO
stuff regarding the TEMAC placement something, whatever the project
does not run completle.

Now I open the other larger ML505 ref design (the main one i think)
the std_usb_ip something..

after again some while, I get some termination regarding some fatal
thing with some GUIerror !!:(

And I only wanted to test some simple C code on ML505 to measure the
sysACE performance.

A task that should take 2 hours max, but now I already spent 5 hours
because the 10.1 mockup.

Ok, back to EDK 9.2SP2
ML505 ref design, it does revup because SP update, it takes 5 hours to
complete
and both the external memories SRAM and DDR2 on ML505 do not work.
the auto SP revup must have messed up something with the memory cores.

Ok, my test program will fit BRAMs so maybe i can finally do that
small C code test
that I wanted todo initially.


Antti
PS, I was thinking that 10.1 is not suggested for ML505, but when i
just NOW opened the ml505 support PDFs they list ISE 10.1 and EDK 10.1

Xilinx, if you say ML505 is to be used with EDK 10.1 then PLEASE fix
the revup or make the 10.1 version of EDK ref design available!

I dont want spend weeks to troubleshoot why xilinx ML505 ref design
doesnt work with EDK 10.1







Article: 130835
Subject: Re: EDK 10.1 first impressions
From: Antti <Antti.Lukats@googlemail.com>
Date: Thu, 3 Apr 2008 03:26:48 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 3 Apr., 12:10, Antti <Antti.Luk...@googlemail.com> wrote:
> Hi
>
> here it goes: I got last week new notebook that is faster then the
> desktop, so I installed 10.x tools there.
>
> And I had a small task to verify something with ML505, so I fire up
> EDK 10.1 open the ML505 reference design, and within 3 minutes EDK
> self-terminates.
>
> So TTFFF (time to first fatal failure) 3 minutes.
>
> Ok, this way my fault i opened the XMP project from compressed folder,
> how foolish from me. But even so EDK should not self-terminate on such
> event IMHO.
>
> Now I open the project from normal folder, after project rev-up the
> file isnt opened.
>
> NEED MANUAL fix!
>
> I have been told that there are many people who have tested the 10.1
> before release, i would have assumed the Xilinx DEFAULT MAIN refernece
> design for ML505 was tested as one of the first test cases, but no it
> wasnt.
>
> Ok, I fix manually the MHS file.
>
> After some hour of implementation run the project fails with some IO
> stuff regarding the TEMAC placement something, whatever the project
> does not run completle.
>
> Now I open the other larger ML505 ref design (the main one i think)
> the std_usb_ip something..
>
> after again some while, I get some termination regarding some fatal
> thing with some GUIerror !!:(
>
> And I only wanted to test some simple C code on ML505 to measure the
> sysACE performance.
>
> A task that should take 2 hours max, but now I already spent 5 hours
> because the 10.1 mockup.
>
> Ok, back to EDK 9.2SP2
> ML505 ref design, it does revup because SP update, it takes 5 hours to
> complete
> and both the external memories SRAM and DDR2 on ML505 do not work.
> the auto SP revup must have messed up something with the memory cores.
>
> Ok, my test program will fit BRAMs so maybe i can finally do that
> small C code test
> that I wanted todo initially.
>
> Antti
> PS, I was thinking that 10.1 is not suggested for ML505, but when i
> just NOW opened the ml505 support PDFs they list ISE 10.1 and EDK 10.1
>
> Xilinx, if you say ML505 is to be used with EDK 10.1 then PLEASE fix
> the revup or make the 10.1 version of EDK ref design available!
>
> I dont want spend weeks to troubleshoot why xilinx ML505 ref design
> doesnt work with EDK 10.1

UUPS, I downloaded the ML505 ref designs yesterday (they where for
9.2)
it seems today the 10.1 versions are available.. sorry I did not check
them

Antti





Article: 130836
Subject: Protecting design from being downloaded on other (similar) FPGA
From: maverick <sheikh.m.farhan@gmail.com>
Date: Thu, 3 Apr 2008 04:16:39 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,
I need to know how can I prohibit a configuration file from being
downloaded on a similar FPGA device. For example, if I have two
similar FPGA boards and I want only one FPGA board to be successfully
programmed with the configuration file whereas if the same
configuration file is downloaded on the other FPGA board, it should
not get programmed. The target device is Virtex II Pro. I know there
is this encryption feature available there for Virtex II and VIrtex II
Pro devices but I am talking about the environment where the FPGAs
will be programmed on startup through host application through PCI and
there is no human intervention for programming the FPGA (or providing
the encryption key). Here is the whole concept. I have a PC system
where a PCI based 'COTS' FPGA card is installed. On startup, my
application programs the FPGA board with the configuration file.
However, if another similar FPGA board is installed in the same PC
system, the application should (somehow) not programm the FPGA or the
FPGA fails to get programmed successfully. I looked into the Device
IDCODE thing but I came to know that the IDCODEs are the same for all
FPGAs belonging to a particular family for example Spartan 3 sc3s1000
FPGA parts will have the same IDCODE. (had it been unique, I would
have stored the IDCODE in my application and on finding a different
IDCODE, I would have aborted the programming device sequence)

I hope I have mentioned my problem statement clearly........

Any suggestion.........

Farhan

Article: 130837
Subject: Re: Protecting design from being downloaded on other (similar) FPGA
From: Antti <Antti.Lukats@googlemail.com>
Date: Thu, 3 Apr 2008 04:32:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 3 Apr., 13:16, maverick <sheikh.m.far...@gmail.com> wrote:
> Hi,
> I need to know how can I prohibit a configuration file from being
> downloaded on a similar FPGA device. For example, if I have two
> similar FPGA boards and I want only one FPGA board to be successfully
> programmed with the configuration file whereas if the same
> configuration file is downloaded on the other FPGA board, it should
> not get programmed. The target device is Virtex II Pro. I know there
> is this encryption feature available there for Virtex II and VIrtex II
> Pro devices but I am talking about the environment where the FPGAs
> will be programmed on startup through host application through PCI and
> there is no human intervention for programming the FPGA (or providing
> the encryption key). Here is the whole concept. I have a PC system
> where a PCI based 'COTS' FPGA card is installed. On startup, my
> application programs the FPGA board with the configuration file.
> However, if another similar FPGA board is installed in the same PC
> system, the application should (somehow) not programm the FPGA or the
> FPGA fails to get programmed successfully. I looked into the Device
> IDCODE thing but I came to know that the IDCODEs are the same for all
> FPGAs belonging to a particular family for example Spartan 3 sc3s1000
> FPGA parts will have the same IDCODE. (had it been unique, I would
> have stored the IDCODE in my application and on finding a different
> IDCODE, I would have aborted the programming device sequence)
>
> I hope I have mentioned my problem statement clearly........
>
> Any suggestion.........
>
> Farhan

V2Pro has no efuse like V5 has, so you cant personalize the FPGAs on
COTS board

so whatever you do for your goal it need something on the boards to be
different (except the FPGA)
the only possibility would be the encryption, if not using it, need
something else

Antti







Article: 130838
Subject: Re: JTAG: First of 4 Spartan-3E always UNKNOWN
From: Andrew Greensted <ajg112@ohm.york.ac.uk>
Date: Thu, 03 Apr 2008 13:09:16 +0100
Links: << >>  << T >>  << A >>
Nico Coesel wrote:
> SOmehow JTAG is extremely sensitive to electrical parameters. IIRC the
> method used to generate the waveforms by Impact is not the best around
> (data and clk are changed simultaneously). I've also had these sort of
> problems on boards with multiple FPGAs. Sometimes adding a small RC to
> the clock (TCK) line may help. You can use an oscilloscope to very
> setup & hold timing on the JTAG bus.

That's interesting. I did wonder how the JTAG bus is driven. I've had a 
small project running in the background for a while to make my own usb 
JTAG module. Perhaps it's time to finish it off.

Andy

Article: 130839
Subject: Re: Protecting design from being downloaded on other (similar) FPGA
From: austin <austin@xilinx.com>
Date: Thu, 03 Apr 2008 05:13:02 -0700
Links: << >>  << T >>  << A >>
All,

Possible solutions exist today for Virtex II, IIP, 4, 5: use encryption. 
  Only the device with the proper key configures.

In Spartan 3A, 3AN, 3ADSP, there is the "DeviceDNA" feature which may be 
used to identify a specific device.  This identification requires a 
customer design to provide the function you desire (reference designs 
are available).

This is really not a good way to do what you ask (encryption is not 
authentication and the device ID is not a standard, so it can make no 
claims of perfect security like one can with SHA), but does work.  More 
advanced would be to have a "secure hash algorithm" like SHA128, which 
could be used with some user readable efuses to provide for a secure 
means to authenticate.

Austin

Article: 130840
Subject: Re: coregenerator bram in synplify pro error
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Thu, 03 Apr 2008 13:27:25 +0100
Links: << >>  << T >>  << A >>
On Wed, 02 Apr 2008 08:35:27 -0700, Duane Clark <user@domaininvalid.com> wrote:

>ni wrote:
>> I am trying to get rams in xilinx to synthesize in synplify pro. I am
>> a novice in syplify pro. I used the core generator to generate BRAM
>> and then since for brams we cannot generate edif files I used ngc2edif
>> to convert it to .ndf. I then added these ndf files into the project.
>> Howewver I seem to get an error with the synplify pro.The core is a
>> simple dual port RAM with a write port A and a read port B
>> The error is following. I dont know how the synplify pro picksup the
>> component from unisim.
>> I have given the components  name as ramb16_s18_s18.
>> 
>> ERROR : Port web of entity unisim.ramb16_s18_s18 is unconnected
>> 
>> The error is regarind port web which is a writ eenable prot of b . but
>> port b is just a read port with we disabled.
>> 
>
>Rather than actually answer the question, can I suggest that you infer 
>BRAM rather than go through that complicated process? As a bonus, 
>inferred BRAM simulates much faster. You would infer BRAM something like:

Err, not necessarily a good idea.

For example, inferring a ROM wide enough to need both data buses and the parity
bits can cause three BRAMs to be used instead of one; to be fair, ISE 9.2
improved on 7.1 in my test case, only inferring twice as many BRAMS as
necessary.

However, initialising the ROM data using functions caused elaboration to take
significant time (of the order of hours for a couple of thousand elements) and
9.2 took twice as long as 7.1. I had to place an assert per memory location to
reassure me it was doing anything at all. There is some n^2 algorithm involved;
you could see it slow down, and doubling the ROM size quadrupled execution time.
I don't know if this has been fixed in 10.1 yet.

But it's a lovely idea when it actually works.

(Incidentally, according to the resulting webcase, the "something I did wrong
while inferring them" was ... inferring them. 
And the suggested instantiation template glossed over the problem of
initialisation entirely.)

Synplify probably handles BRAM inference much better; just be aware that relying
on it limits portability.

- Brian

Article: 130841
Subject: Re: EDK 10.1 first impressions
From: Patrick Dubois <prdubois@gmail.com>
Date: Thu, 3 Apr 2008 05:45:56 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 3 avr, 06:26, Antti <Antti.Luk...@googlemail.com> wrote:
> UUPS, I downloaded the ML505 ref designs yesterday (they where for
> 9.2)
> it seems today the 10.1 versions are available.. sorry I did not check
> them
>
> Antti

Still, I think that you have a valid point that the rev up should be
working properly. Ref designs are nice but most people will have
custom designs in 9.2 that they want to migrate to 10.1.

Personnaly I'll try to wait until at least the first service pack, OR
until I encounter a bug in 9.2 that is fixed in 10.1...

Patrick


Article: 130842
Subject: Re: async clk input, clock glitches
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 3 Apr 2008 13:47:09 +0100
Links: << >>  << T >>  << A >>
Torsten Landschoff wrote:
>
> Do you know another archive?
>
archive.org 



Article: 130843
Subject: Beginner's silly question about ICAP
From: g.drozdzowski@gmail.com
Date: Thu, 3 Apr 2008 06:02:11 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi Comrade,

I run into troubles trying to read anything using ICAP.

I set "-g security:none", just in case.

When I try to read for example STAT Register, BUSY goes HIGH when I
switch to reading and stays that way. I deselect device (i.e. assert
CE to HIGH) first then toggle WRITE.

Output O[7:0] is set to X"9F", all the time.

What may be the reason, any guesses?

What am I missing?

Cheers,
[g.d.]

Article: 130844
Subject: Re: Beginner's silly question about ICAP
From: austin <austin@xilinx.com>
Date: Thu, 03 Apr 2008 06:19:41 -0700
Links: << >>  << T >>  << A >>
g.d.

ICAp is nothing but a simple 2:1 multiplexer which provides internal 
access to all those "normal" external configuration interface pins.

It sounds like PROG is being pulled internally, which causes the device 
to lose configuration, or something simple like that.

After instantiating the ICAP primitive, be sure that all the connections 
you make to it have the same logical function as you would do externally 
on the same pins.

In fact, debugging can be done by doing whatever it is, externally, and 
then putting it back inside (if you get really desperate).

Be sure to go over all the configuration signals, and their use, in the 
User's configuration guide for your part.

Austin

Article: 130845
Subject: Re: coregenerator bram in synplify pro error
From: Jeff Cunningham <jcc@sover.net>
Date: Thu, 03 Apr 2008 09:50:24 -0400
Links: << >>  << T >>  << A >>
Brian Drummond wrote:
>>>
>> Rather than actually answer the question, can I suggest that you infer 
>> BRAM rather than go through that complicated process? As a bonus, 
>> inferred BRAM simulates much faster. You would infer BRAM something like:
> 
> Err, not necessarily a good idea.
> 
> For example, inferring a ROM wide enough to need both data buses and the parity
> bits can cause three BRAMs to be used instead of one; to be fair, ISE 9.2
> improved on 7.1 in my test case, only inferring twice as many BRAMS as
> necessary.
> 
> However, initialising the ROM data using functions caused elaboration to take
> significant time (of the order of hours for a couple of thousand elements) and
> 9.2 took twice as long as 7.1. I had to place an assert per memory location to
> reassure me it was doing anything at all. There is some n^2 algorithm involved;
> you could see it slow down, and doubling the ROM size quadrupled execution time.
> I don't know if this has been fixed in 10.1 yet.
> 
> But it's a lovely idea when it actually works.
> 
> (Incidentally, according to the resulting webcase, the "something I did wrong
> while inferring them" was ... inferring them. 
> And the suggested instantiation template glossed over the problem of
> initialisation entirely.)
> 
> Synplify probably handles BRAM inference much better; just be aware that relying
> on it limits portability.
> 
> - Brian

Another limitation I have heard is that you can't infer dual port ram of 
differing port widths.

-Jeff

Article: 130846
Subject: Re: counterfeit Xilinx ?
From: Craig <craig.taylor@xilinx.com>
Date: Thu, 3 Apr 2008 07:01:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 2, 4:59=A0pm, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> Peter Alfke wrote:
> > On Apr 2, 3:08 pm, Jim Granville <no.s...@designtools.maps.co.nz>
> > wrote:
>
> >>craig.tay...@xilinx.com wrote:
>
> >>>In many cases Xilinx will not be
> >>>able to assist you in determining if those suspect devices are
> >>>legitimate or usable.
>
> >>Hmmm - so these are no counterfeit at all (in the literal sense)
>
> >>but relabeled devices ? - Maybe Xilinx die from Easypath,
> >>or do Xilinx have 'creepage' issues on their test rejects ?
>
> >>-jg
>
> > Jim, this is all idle speculation. At least, Jon was desrcribing his
> > dubious source openly.
> > When it comes to things that you cannot easily evaluate (like FPGAs,
> > microprocessors, food, medicine etc) you do not want to buy them at
> > the flea market.
>
> Agreed
>
> > The fact that the parts look like the real thing is incidental.
>
> Yes and no. If it were my company, I'd be interested in just
> HOW the parts got to be there.
>
> Do I need to tighten up the Testers, or Fabs, or do I need
> to laser mark EasyPath devices ? - or are they
> someone elses pulls, nicely refurbished
> (possible, but rather unlikely, due to erratic volumes)
>
> Grey market devices are usually 'easy dollars',
> so a speed-grade hike is one easy action.
> Intel has struggled with this.
>
> Xilinx's call - I guess this must be in the noise floor for them.
>
> -jg- Hide quoted text -
>
> - Show quoted text -

Let me say this
Xilinx is investigating the issue of counterfeit devices.  We have
taken steps to increase awarness of the issue with other companies in
the industry.  We are working with several government agencies on the
issue.  Many time we see that these parts are remarks.  In some cases
they are remarked devices that originally were not even Xilinx
devices.  Often they are really old devices that are marked to look
young, faster than they are, or of a higher grade then they were.  I
have not seen pollution of reject materials from our supply base.
There are very tight controls on reject and scrap materials, with
several levels of validation.  Xilinx has personnel (XILINX Employees)
in each of our factory partners.

We are also looking at the issue proactively.  We are investigating
several new marking protocols and security features that would be
nearly impossible to duplicate or replicate. Our intent is to increase
the amount of time and money it would take to remark devices to look
like true Xilinx, but this is still off in the future.

I recieved a phone call from someone reading my last post.  They were
not very happy about my authorized channel statement.  I provide this
information for peice of mind.  If you buy parts from independent
distributors that is not my issue.  If the independent Disti is
legitimately buying for an authorized Xilinx channel and can
demonstrate a clean line of custody you may be Okay.  It is your own
comfort level with that transaction.  However, some folks choose to
buy parts from the broker market.  There are some good resources in
this market, but the devices that are coming in an out of this have a
much higher rate of legitimacy issues.  How many hands to you want
your parts going through before you put them in your end product?  It
is really a question of Care, Custody, & Control.  If you are buying
for the Xilinx Disti, the CCC line is clear and easily supportable buy
Xilinx warranty.  Then when you get to 3rd, 4th, 5th partys, you have
lost whatever CCC you might have warrented with the 2nd party
purchase.

I hope that this help further clarify.

Article: 130847
Subject: Re: Beginner's silly question about ICAP
From: Jens Hagemeyer <jenze@hni.upb.de>
Date: Thu, 3 Apr 2008 07:05:53 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 3 Apr., 15:02, g.drozdzow...@gmail.com wrote:
> Hi Comrade,
>
> I run into troubles trying to read anything using ICAP.
>
> I set "-g security:none", just in case.
>
> When I try to read for example STAT Register, BUSY goes HIGH when I
> switch to reading and stays that way. I deselect device (i.e. assert
> CE to HIGH) first then toggle WRITE.
>
> Output O[7:0] is set to X"9F", all the time.
>
> What may be the reason, any guesses?
>
> What am I missing?
>
> Cheers,
> [g.d.]

Hi g.d.

looks like you're triggering a "SelectMap abort sequence" when
switching from read to write. Consult the User Guide on how to avoid
this, i guess your CS handling is not correct.

Jens

Article: 130848
Subject: Re: "Number of BSCANs: 2 out of 1 200%"
From: Pablo <pbantunez@gmail.com>
Date: Thu, 3 Apr 2008 08:29:29 -0700 (PDT)
Links: << >>  << T >>  << A >>
OK, i have just used the secondary ports from the opb_mdm to connect
the icon core. Now I am trying to debug with the Chipscope Analyzers,
but I get only one value. That is, I have included a clock port, so it
sould appears as 101010101 and so on. The real value is 1111111111. It
seems like system only does a unique sample but it shows 512 samples.
Does anyone have the same result?. What must I configure to show a
clock signal up and down?

Again, my best regards


Article: 130849
Subject: Re: async clk input, clock glitches
From: Muzaffer Kal <kal@dspia.com>
Date: Thu, 03 Apr 2008 08:42:24 -0700
Links: << >>  << T >>  << A >>
On Thu, 3 Apr 2008 00:33:33 -0700 (PDT), Torsten Landschoff
<t.landschoff@gmx.de> wrote:

>Hi Peter,
>
>On 3 Apr., 01:49, Peter Alfke <pe...@xilinx.com> wrote:
>
>> Well, if you worry about double-clocking, there are simple bad-aid
>> fixes that let you live with the double edges: click onhttp://www.nalanda.nitc.ac.in/industry/appnotes/xilinx/documents/xcel...
>> which shows two different ways to avoid the effect of double-edges on
>> a clock.
>> I wrote that long ago, and published it in Xilinx XCell magazine #34
>
>I was curious about that article. I don't currently have any related
>problem but learning these tricks might help me down the road.
>
>Unfortunately the link you posted is dead. I tried to dig it up from
>the xcell archives on xilinx.com, but the last issue available is #48.
>It would be nice to have the older issues available as well,
>especially for newcomers who can still learn some basic/historical
>stuff from that.
>
>Do you know another archive?
>
>Greetings, Torsten

For an official source of older XCell magazines go here:
ftp://ftp.xilinx.com/pub/documentation/xcell/00_index.htm

the specific issue is here:
ftp://ftp.xilinx.com/pub/documentation/xcell/xcell34.pdf

with the article starting on page 54.




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