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 28150

Article: 28150
Subject: Re: Question about programming xcv100
From: Ray Andraka <ray@andraka.com>
Date: Sat, 23 Dec 2000 04:38:16 GMT
Links: << >>  << T >>  << A >>
This question comes up more often than most of us care to admit.  The bitstream
is 
largely considered proprietary, and there is plenty of potential for doing
damage if
not correct.  Before attempting this, one should be thoroughly familiar with the
fpga 
details and then some.  Rather than trying to re-invent the tools, you'd be
better off
working with the tools.  The xilinx tools do give you several entry points into
the tools
from which you can bypass the previous stuff without getting into the nuts and
bolts of the
bitstream.  First stop would be using any one of a number of third party entry
tools. The synthesizers as 
well as the schematic translators all have one of two formats of the output to
go into the 
FPGA point tools.  Those are edif and xnf.  The edif format is pretty much an
industry standard,
and while it is not real user friendly, it could be used to enter a design
directly.  The contents of the 
edif netlist are xilinx primitives along with any attrubutes passed from the
source, plus 
block boxes for other linked in edif netlists.  The xnf format is an older
xilinx specific format
which frankly is a little easier to decipher or parse.  I don't know how long,
going into the future 
it will continue to be supported, as the clear preference is for edif.  The
advantage of going in to the
front end of the xilinx tools is that you can link in third party macros, and
you get the full benefit
of the mapper, floorplanner, place and route and bitstream generator.

If you don't want to use those for whatever reason (evolution is one of the more
valid reasons I've heard),
then you could use jbits to generate the bitstream from your own stuff.  If you
are so inclined, you could also enter the design through the FPGA editor,
bypassing everything but the bitstream generation, at the espense of more
tedious work.



longwayhome@my-deja.com wrote:
> 
> Hi
> I bought an xsv100 board from Xess, which has a Xilinx xcv100 chip on
> it. With the board came a utility which can send compiled bitstreams to
> the chip. I'd like to manually generate the bitstreams though, rather
> than compile them from a vhdl spec though, as my intention is to
> program it using evolutionary algorithms and I think this would be
> easier and faster than actually generating vhdl and compiling that then
> sending that to the chip.
> 
> Does anyone know where I can find a spec which would show exactly how
> the bitstreams are interpreted by xcv100 ? I've already had an
> unsuccessfull look at the Xilinx site (but i've had problems finding
> what i want there before...)
> 
> I'm a complete beginner at this, all advice greatfully accepted.
> 
> Thanks
> 
> David
> 
> Sent via Deja.com
> http://www.deja.com/

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  or http://www.fpga-guru.com

Article: 28151
Subject: MAKE LOTS OF MONEY!! NOT A SCAM!! IT REALLY WORKS!!
From: "keat3" <keat3@bellsouth.net>
Date: Sat, 23 Dec 2000 00:03:28 -0500
Links: << >>  << T >>  << A >>
SERIOUSLY THIS IS NOT A SCAM! LOTS OF CASH, FAST AND COMPLETELY LEGAL, THIS
REALLY WORKS!! THIS REALLY CAN MAKE YOU EASY MONEY!! IT WORKS!!! BUT YOU
HAVE TO FOLLOW IT TO A LETTER FOR IT TO WORK!!!! A little while back, I was
browsing through newsgroups, just like you are now, and came across an
article similar to this that said you could make thousands of dollars within
weeks with only an initial investment of $6.00! So I thought,"Yeah, right,
this must be a scam", but like most of us, I was curious, so I kept reading.
Anyway, it said that you send $1.00 to each of the 6 names and address
stated in the article. You then place your own name and address in the
bottom of the list at #6, and post the article in at least 200 newsgroups.
(There are thousands) No catch, that was it. So after thinking it over, and
talking to a few people first, I thought about trying it. I figured what
have I got to lose except 6 stamps and $6.00, right? Like most of us I was a
little skeptical and a little worried about the legal aspects of it all. So
I checked it out with the U.S. Post Office (1-800-725-2161 or www.usps.gov)
and they confirmed that it is indeed legal! Then I invested the measly
$6.00. Well GUESS WHAT!! ... Within 7 days, I started getting money in the
mail! I was shocked! I figured it would end soon, but the money just kept
coming in. In my first week, I made about $25.00. By the end of the second
week I had made a total of over $1,000.00! In the third week I had over
$10,000.00 and it's still growing. This is now my fourth week and I have
made a total of just over $42,000.00 and it's still coming in rapidly. It's
certainly worth $6.00, and 6 stamps. Let me tell you how this works and most
importantly, why it works.... also, make sure you print a copy of this
article NOW, so you can get the information off of it as you need it .. STEP
1: Get 6 separate pieces of paper and write the following on each piece of
paper "PLEASE PUT ME ON YOUR MAILING LIST." Now get 6 US $1.00 bills and
place ONE inside EACH of the 6 pieces of paper so the bill will not be seen
through the envelope to prevent thievery. Next, place one paper in each of
the 6 envelopes and seal them. You should now have 6 sealed envelopes, each
with a piece of paper stating the above phrase, your name and address, and a
$1.00 bill. What you are doing is creating a service by doing this. THIS IS
ABSOLUTELY LEGAL! Mail the 6 envelopes to the following addresses:

#1)Ike, 2900 Canby Ct., Northfield, MN 55057
#2)D. Gerow, P.O. Box 579574, Modesto, CA 95357-9574
#3)V. Williams, 222 East Avenue G Hutchinson 67501
 #4)J.Morton, 475 N.W. Walnut Blvd., Corvallis, OR 97330
#5)S. Dorman, P.O. Box 4222, Ft. Polk, LA 71459
#6)D. Abu Harb,2238 New Hope Church Rd. Raleigh,NC 27604

STEP 2: Now take the #1 name off the list that you see above, move
the other names up (6 becomes 5, 5 becomes 4, etc...) and add YOUR Name as
number 6 on the list .. STEP 3: Change anything you need to, but try to keep
this article as close to original as possible. Now, post your amended
article to at least 200 newsgroups (I think there are close to 24,000
groups). All you need is 200, but remember, the more you post, the more
money you make!!! .. DIRECTIONS ---HOW TO POST TO NEWSGROUPS---- Step 1) You
do not need to re-type this entire letter to do your own posting. Simply put
your cursor at the beginning of this letter and drag your cursor to the
bottom of this document, and select 'copy' from the edit menu. This will
copy the entire letter into the computers memory. Step 2) Open a blank
"notepad" file under accessories in windows and place your cursor at the top
of the blank page. From the 'edit' menu select 'paste'. This will paste a
copy of the letter into notepad so that you can add your name to the list.
Step 3) Save your new notepad file as a .txt file. If you want to do your
postings in different settings, you'll always have this file to go back to.


Article: 28152
Subject: Re: Question about Xilinx pins at high-frequency
From: murray@pa.dec.com (Hal Murray)
Date: 23 Dec 2000 06:35:12 GMT
Links: << >>  << T >>  << A >>

In article <ee6f135.10@WebX.sUN8CHnE>,
 "Pascal C." <> writes:
> The pins on which I am trying to reduce the drive are LVTTL.  I've constrained
> them to a Clock to out of 6 ns, to allow some setup time (the clock is 131M, so
> clock period is about 7.8ns).  Under 12 mA, it tells me it can't possibly meet
> a clock to out of 6 ns.  And fails.  
> 
> I finally got an answer from Xilinx TechSup.  They told me I had two choices:
> a) ease off the constraints so that PAR will complete, or b) change all pins
> manually.

The key thing you have to understand is the data sheet.  As you set the drive
to lower current, the clock-out takes longer.

Be thankful that you are getting error messages rather than circuits
that don't work when the chip gets warm and/or VCC is a bit low.

-- 
These are my opinions, not necessarily my employers.  I hate spam.

Article: 28153
Subject: Re: Methodology
From: murray@pa.dec.com (Hal Murray)
Date: 23 Dec 2000 06:41:18 GMT
Links: << >>  << T >>  << A >>


> (3) Do builds from the command line. Learning how to use ``make'' will
> vastly repay the effort.

How many other people would be happier if Xilinx "supported" make style
development?


I think the key part that I haven't found is a file flow diagram.
What files are "source" and need to be preserved by RCS/CVS/whatever?
What files are machine generated (and easy to recreate) and
which programs make them?  Which files do those programs read?

Yes, I'm fishing for the data needed to build a makefile.

An app-note would be a wonderful idea.

-- 
These are my opinions, not necessarily my employers.  I hate spam.

Article: 28154
Subject: Re: Methodology
From: "Joel Kolstad" <JoelKolstad@Earthlink.Net>
Date: Sat, 23 Dec 2000 08:33:06 GMT
Links: << >>  << T >>  << A >>
"Hal Murray" <murray@pa.dec.com> wrote in message
news:921hee$sv0@src-news.pa.dec.com...
> How many other people would be happier if Xilinx "supported" make style
> development?

Although they don't really "support" it, I don't think they at all opposed
to it either...

> I think the key part that I haven't found is a file flow diagram.
> What files are "source" and need to be preserved by RCS/CVS/whatever?
> What files are machine generated (and easy to recreate) and
> which programs make them?  Which files do those programs read?

I think the easiest way to determine these things is to look in the log file
generated by the "pushbutton" flow and then read up on the command line
parameters for all the programs invoked.  It would be nice if someone
summarized this all into a chapter somewhere.

---Joel Kolstad




Article: 28155
Subject: Re: Metastability rant (was Re: dual port ram for altera)
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sat, 23 Dec 2000 09:59:31 +0000
Links: << >>  << T >>  << A >>


Hal Murray wrote:

<snip>

>
> Similarly, I'd like a tool that would raise a red flag if a signal
> from a different clock goes to more than one FF.
>

<end-snip>

This isn't all that hard to do by post-processing e.g. the synthesis or post MAP
simulation netlists *except* that the simple minded way of doing it generates screeds &
screeds of junk warnings.  This comes about from the typical situation where for example
you have some sort of bus. Synchronising the ``request'' bit is all you need in general
since when that's cleanly across domains you can assume that all the rest -
address/data/direction etc. - has been stable for at least 1 whole period of the target
domain clock.

Therefore what's needed is some attribute you can set at the HDL/schematic level
that says ``this is a synchroniser FF'' and propagates all the way through the build
chain. Then you can do both the reg-flagging stuff  and <dream -on> put some
metastability analysis into the STA [Trace] tools <dream -off>.

Peter: Here's a suggestion - How about a new timing constraint

INST "foo" SYNCHRONISER;




Article: 28156
Subject: Re: Is it necessary to synchronize the reset signal in an FPGA ?
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sat, 23 Dec 2000 10:07:22 +0000
Links: << >>  << T >>  << A >>


Hal Murray wrote:

> > I just had a look at the online docs, and it's pretty much all covered
> > in the first few pages of:
> >
> > Synthesis and Simulation Design Guide
> >  Chapter 4: Designing FPGAs with HDL
> >   Using Dedicated Global Set/Reset Resource
>
> Thanks.  Interesting that it doesn't say anything like that
> in the data sheet.
>
> --
> These are my opinions, not necessarily my employers.  I hate spam.

But with all this there is still no way [according to Evan] to turn off the
implicit GSR that happens during config.


Article: 28157
Subject: Re: Methodology
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sat, 23 Dec 2000 10:38:44 +0000
Links: << >>  << T >>  << A >>


Hal Murray wrote:

> > (3) Do builds from the command line. Learning how to use ``make'' will
> > vastly repay the effort.
>
> How many other people would be happier if Xilinx "supported" make style
> development?
>
> I think the key part that I haven't found is a file flow diagram.
> What files are "source" and need to be preserved by RCS/CVS/whatever?
> What files are machine generated (and easy to recreate) and
> which programs make them?  Which files do those programs read?
>
>

The answer to this is basically every text file that's not generated by one
of the tools in the flow. So if the flow is something like

                Source files <-- Verilog, VDHL

                Synthesis <-- side files e.g. constraints, IO buffer defs
etc.

                NGDBUILD <-- UCF + e.g. CoreGen netlists

                MAP <-- Extra PCF constaints

                PAR/TRCE  [I always run these as a pair]

                BitGen/PROMGen

at each of these stages I use the -f flag to pass arguments to the tools so
that the arg files can be archived as well. Then roughly speaking all the
stuff coming in from the right is archived.

o I've got a lot of Perl scripts that hack about in the flow that get
CVS'ed.

o When I do a release I'll generally archive all the tool log/report files.
Not really necessary but useful.

o Don't forget the most important of all - the makefile itself.

All this can add a couple of hours overhead when checking in all this stuff
to the archive but I've lost count of the number of times I've spotted
something wrong during the actual checkin process. Classically its things
like changing the polarity on some register bit - which will make the s/w
break.

After all this what you've got is a *reproducible* version of the big green
GUI button:

gmake <design>.exo

then go away & have a decent lunch, go running, play a game of squash, or
even get on with the next design.


Article: 28158
Subject: Re: Methodology
From: Dave Vanden Bout <devb@xess.com>
Date: Sat, 23 Dec 2000 06:14:54 -0500
Links: << >>  << T >>  << A >>


Hal Murray wrote:

> > (3) Do builds from the command line. Learning how to use ``make'' will
> > vastly repay the effort.
>
> How many other people would be happier if Xilinx "supported" make style
> development?
>
> I think the key part that I haven't found is a file flow diagram.
> What files are "source" and need to be preserved by RCS/CVS/whatever?
> What files are machine generated (and easy to recreate) and
> which programs make them?  Which files do those programs read?
>
> Yes, I'm fishing for the data needed to build a makefile.
>
> An app-note would be a wonderful idea.

We published an appnote about using makefiles with Foundation and
FPGA-Express at http://www.xess.com/manuals/fndmake.pdf.  It doesn't address
the file dependency issue, but it shows which programs are called and in
what sequence.




>
>
> --
> These are my opinions, not necessarily my employers.  I hate spam.

--
|| Dr. Dave Van den Bout   XESS Corp.               (919) 387-0076 ||
|| devb@xess.com           2608 Sweetgum Dr.        (800) 549-9377 ||
|| http://www.xess.com     Apex, NC 27502 USA   FAX:(919) 387-1302 ||



Article: 28159
Subject: evolving bitstreams
From: Ben Franchuk <bfranchuk@jetnet.ab.ca>
Date: Sat, 23 Dec 2000 04:56:21 -0700
Links: << >>  << T >>  << A >>
longwayhome@my-deja.com wrote:
> > If you want to put  on any Xilinx ( or Altera or
> Atmel)
> > FPGAs, don't do it !

> I didn't actually want to treat the bitstreams themselves as a piece
> of 'dna' to mutate/breed etc although now that you've mentioned that
> idea an XC6200 board would be a nice thing to have (if xilinx have any
> such boards lying around destined for wastage... :-)

I don't think any kind of evolving is possible in the line of digital
circuits in standard logic.Comparing FPGA's with carbon-based-logic is
like comparing Apples and Turnips. The closest I can see something is
with cellular logic like "life".
Ben. 
-- 
"We do not inherit our time on this planet from our parents...
 We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk

Article: 28160
Subject: Re: Synplicity and multiple input IOB flops...how to specify which one goes in the IOB?
From: "Austin Franklin" <austin@darkroo98m.com>
Date: 23 Dec 2000 14:35:34 GMT
Links: << >>  << T >>  << A >>
Solved...

The answer (provided by Hal Murray, thanks Hal!) was to do the following:

//
// The MF input flops should be in the IOB, since the MF clock is much
faster than the LF
// and in order to do this, we have to use xc_props to pass the attribute
to the Xilinx map program
// or it'll map the LF flops into the IOB...
//
input	[15:0]	I_c_adc_din ;
reg	[15:0]	c_adc_lf_din	/* synthesis syn_preserve = 1 xc_props =
"IOB=FALSE" */ ;
reg	[15:0]	c_adc_mf_din	/* synthesis syn_preserve = 1 xc_props = "IOB=TRUE"
*/ ;


It appears the "syn_useioff" can only be on input/output statements, and
are ignored on reg statements...


Austin Franklin <austin@darkroo98m.com> wrote in article
<01c06bcb$b13d6da0$2404f7a5@drt1>...
> I have an input that has two flops for destinations.  I want one of them
to
> be in the IOB, and the other flop to use a CLB flop, and the tools do
> that....but it's the wrong one that ends up in the IOB.
> 
> I have an <all> syn_useioff in the .sdc file, and I also use the map
option
> -pr b...that's how the FFs get in the IOBs in the first place...and I've
> tried both specifying that specific register as syn_useioff in the .sdc
> file, as well as the <all>, and I've tried giving the Verilog the /*
> synthesis syn_useioff = 1 */ on that particular reg statement....nothing
> has worked yet.
> 
> When I use look at the technology mapping from Synplicity, it doesn't
show
> what flops are IOB flops...when I bring up the .ncd file (pre PAR) in
> Floorplanner...the FF for one of the two destination registers is already
> in the IOB...but it's the wrong one...
> 
> So, how do I tell Synplicity (preferably) specifically which flop I want
in
> the IOB?
> 
> 

Article: 28161
Subject: Re: Synplicity and multiple input IOB flops...how to specify which one goes in the IOB?
From: "Austin Franklin" <austin@darkroo98m.com>
Date: 23 Dec 2000 14:38:31 GMT
Links: << >>  << T >>  << A >>


Magnus Homann <d0asta@mis.dtek.chalmers.se> wrote in article
<lt4rzwi2kh.fsf@mis.dtek.chalmers.se>...
> "Austin Franklin" <austin@darkroo98m.com> writes:
> 
> > I have an input that has two flops for destinations.  I want one of
them to
> > be in the IOB, and the other flop to use a CLB flop, and the tools do
> > that....but it's the wrong one that ends up in the IOB.
> 
> * Watch out for setup and hold timing.
> * You could use UCF to specify IOB TRUE, and turn it off in Synplify.

Getting the flops that are being clocked by the faster clock in the IOBs is
the goal...  Setup and hold times on the slower clock flops are handled by
inverting the clock....that gives plenty of setup and hold.  Thanks!


Article: 28162
Subject: Re: Synplicity and multiple input IOB flops...how to specify which one goes in the IOB?
From: "Austin Franklin" <austin@darkroo98m.com>
Date: 23 Dec 2000 14:43:29 GMT
Links: << >>  << T >>  << A >>
>   You could use the xc_props attribute from Synplify to tag the flops
with the
> appropriate Xilinx attribute IOB = (TRUE|FALSE).

That is what I ended up doing...and confirmed it does work. Thanks!

> The following example should do what you are asking for (note that I  had
to
> use the syn_preserve attribute so that all the flops don't get merged):

Yep, I found out a while ago about that I needed to use syn_preserve in
this situation ;-)


Article: 28163
Subject: Re: Question about programming xcv100
From: longwayhome@my-deja.com
Date: Sat, 23 Dec 2000 15:05:08 GMT
Links: << >>  << T >>  << A >>
In article <3A442CBC.3A9401F8@andraka.com>,
  Ray Andraka <ray@andraka.com> wrote:
> This question comes up more often than most of us care to admit.  The
bitstream
[ snip ]

Hi

Thanks for taking the time to respond to my question. I appreciate it.

David


Sent via Deja.com
http://www.deja.com/

Article: 28164
Subject: Re: Synplicity and multiple input IOB flops...how to specify which one goes in the IOB?
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 23 Dec 2000 17:49:11 +0100
Links: << >>  << T >>  << A >>
"Austin Franklin" <austin@darkroo98m.com> writes:

> Magnus Homann <d0asta@mis.dtek.chalmers.se> wrote in article
> <lt4rzwi2kh.fsf@mis.dtek.chalmers.se>...
> > "Austin Franklin" <austin@darkroo98m.com> writes:
> > 
> > > I have an input that has two flops for destinations.  I want one of
> them to
> > > be in the IOB, and the other flop to use a CLB flop, and the tools do
> > > that....but it's the wrong one that ends up in the IOB.
> > 
> > * Watch out for setup and hold timing.
> > * You could use UCF to specify IOB TRUE, and turn it off in Synplify.
> 
> Getting the flops that are being clocked by the faster clock in the IOBs is
> the goal...  Setup and hold times on the slower clock flops are handled by
> inverting the clock....that gives plenty of setup and hold.  Thanks!

Ah, you are lucky! You have a _slow_ clock. I always seem to have a fast clock and then smoe faster... ;-)

Homann
-- 
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se

Article: 28165
Subject: Re: Pull-up
From: rk <stellare@nospamplease.erols.com>
Date: Sat, 23 Dec 2000 16:05:37 -0500
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> 
> It is possible, however I strongly recommend you use an external pullup.  The
> internal pull ups are weak pull ups sufficient to tie an unconnected pin high.
> However when that pin has a trace and loads attached, the pull up value is
> really too small to ensure a) that the trace does not act as an antenna and b)
> that the open drain output goes back high in a reasonable amount of time.  The
> high impedance (>100K) of the internal pullup does little to guarantee this.

t = rc = 100x10^3 x 20x10^-12  (quite liberal)
       = 2 us

2.2 rc (10%-90%) == 4.4 us

tr (virtex, xqr4000xl) max = 250 ns

==> external pullup.  don't know spartan xl, original question.

for those of the actelian persuasion, tr (sx-a) max = 50 ns.

----------------------------------------------------------------------
rk                               How the hell do I know? I'm just a
stellar engineering, ltd.        common, ordinary, simple savior of
stellare@erols.com.NOSPAM        America's destiny.
Hi-Rel Digital Systems Design    -- Pat Paulsen

Article: 28166
Subject: spartan-II power supply sequencing problem
From: "R Sefton" <rsefton@home.com>
Date: Sat, 23 Dec 2000 22:07:33 GMT
Links: << >>  << T >>  << A >>
We were having a very strange problem after power-up
(intermittently, maybe 1 of every 8 power cycles) where an XC2S150
would not respond to PROG/ and thus could not be configured. The
device would release INIT/ even though PROG/ was still asserted,
then INIT/ would stay high despite several high/low cycles of PROG/.
We even tried cycling CCLK continuously (watching for INIT to go low
again when it detected bogus config data) with the theory that the
device came up in the wrong config mode and hadn't totally lost its
brains.

We suspected power sequencing problems from the beginning, and we
were right. The 3.3V VCCO supply would ramp up from 0 to 95% in
about 12ms. The 2.5V VCCINT supply (regulated on board from 5V)
would ramp up very quickly from 0 - 95% (~250us). The 3.3V supply
was slightly above 1V (the level required for configuration) when
the 2.5V supply reached 95%. We ended up eliminating the problem by
delaying the 2.5V power-up by several milliseconds, but the ramp up
was still very quick (much faster than the 2ms recommended in the
Spartan-II data sheet).

The problem has been eliminated, but I want to understand the
mechanism. Anyone know what may have been going on inside the device
that would cause it to release INIT/ with PROG/ still low and then
ignore all future assertions of PROG/?  The only way to clear the
condition was to cycle power.

Thanks,

Bob Sefton


Article: 28167
Subject: Re: Question about programming xcv100
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Sat, 23 Dec 2000 14:25:19 -0800
Links: << >>  << T >>  << A >>
David,
let me talk you out of what you seem to be trying.
The vast majority of the bits in the bitstream has a specific function,
activating a pass transistor, controlling a multiplexer, driving a metal
line etc. ( A few bits are just left-over fill bits, but only a few)
If you start "evolving" bitstreams, you will most likely create massive
contention on the chip, i.e. two opposite signals driving the same piece
of metal. Although the individual contention current may be just a few mA,
multiple thousands can literally melt down the plastic package and destroy
the chip.

Xilinx used to make the XC6200 chip that did not have multiple outputs
able to drive the same line, so it was bullet-proof, and it became the
darling of experimenters like you.
Unfortunately, XC6200 did not find a home in commercial applications, so
we stopped making it.

If you want to put evolving bitstreams on any Xilinx ( or Altera or Atmel)
FPGAs, don't do it !
I copied Delon Levi here at Xilinx who may have additional thoughts.

Peter Alfke, Xilinx Applications
================================

longwayhome@my-deja.com wrote:

> Hi
> I bought an xsv100 board from Xess, which has a Xilinx xcv100 chip on
> it. With the board came a utility which can send compiled bitstreams to
> the chip. I'd like to manually generate the bitstreams though, rather
> than compile them from a vhdl spec though, as my intention is to
> program it using evolutionary algorithms and I think this would be
> easier and faster than actually generating vhdl and compiling that then
> sending that to the chip.
>
> Does anyone know where I can find a spec which would show exactly how
> the bitstreams are interpreted by xcv100 ? I've already had an
> unsuccessfull look at the Xilinx site (but i've had problems finding
> what i want there before...)
>
> I'm a complete beginner at this, all advice greatfully accepted.
>
> Thanks
>
> David
>
> Sent via Deja.com
> http://www.deja.com/


Article: 28168
Subject: Re: really fast counter in SpartanXL?
From: "markp" <map@nospam_dial.pipex.com>
Date: Sat, 23 Dec 2000 23:19:58 -0000
Links: << >>  << T >>  << A >>

"Theron Hicks" <hicksthe@egr.msu.edu> wrote in message
news:3A37CD2C.21969FDB@egr.msu.edu...
> Can anyone give me the "best" way to implement a _fast_ counter in a
> SpartanXL design?  I need a 16 bit counter with enable and reset.clock
> on negative edge preferred but not critical.  I don't need the output to
> be synchronous because I am counting to measure pulse width so I can
> wait for the final result to ripple through to the output.  The _only_
> factor of importance is _speed_.  Should I use logiBLOX or should I
> write my owm or should I forcibly implement it using some unknown (to
> me) tool?  I need to get up to 204.8MHz toggle frequency.  The output in
> counts will be latched after the pulse is completed and the resulting
> count values will be passed through a tri-state output of some sort.
>
> Thanks,
> Theron J. Hicks
>

The fastest counters in my experience are LFSRs (linear feedback shift
registers) - the outputs aren't  binary and you only get (2^n)-1 states (all
zeros aren't valid), but these are basically shift registers with an xor
feedback term and they use the fast carry logic. Maybe you can get software
to do the reverse conversion if that is not in the critical path. Search
Xilinx website for LSFRs.

Mark.



Article: 28169
Subject: Re: Power consumption FPGA...
From: John Larkin <jjlarkin@highlandSNIPTHIStechnology.com>
Date: Sat, 23 Dec 2000 15:49:35 -0800
Links: << >>  << T >>  << A >>
On Wed, 22 Nov 2000 15:36:05 +0100, "Jurjen Boss" <jboss@lmint.com>
wrote:

>Hi,
>
>We want to implement a Xilinx Spartan-II FPGA, type XC2S50, in our
>(excisting) application. I'm trying to estimate the current supply of this
>device by using the datasheets ("Spartan-II 2.5V FPGA Family: DC and
>Switching Charateristics"). From this datasheet I get the following
>information:
>-    Iccintq = 50mA;    (supply current internal part)
>-    Iccoq = 2mA;       (supply current I/O-part)
>-    Iccpo=500mA;      (ramp rate 2ms)
>
>Does this FPGA needs so much current at power-up? How can this ramp rate be
>adjusted? I just can't imagine that this FPGA needs 500mA at power-up. I
>thought these devices where low-power!?! Is there some information available
>on this subject?
>
>Regards,
>
>Jurjen
>

Jurjen,

At low supply voltages, before all the CMOS gates have made up their
minds to be hard high or low, all sorts of P and N-channel FETS can be
conducting. This can draw lots of current. If your supply can muscle
past this point and pull Vcc up to the rated voltage, good; if not,
the supply can current limit and the system can hang.

Most CMOS parts behave this way.

John


Article: 28170
Subject: Re: really fast counter in SpartanXL?
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Sat, 23 Dec 2000 15:51:10 -0800
Links: << >>  << T >>  << A >>


markp wrote:

> The fastest counters in my experience are LFSRs (linear feedback shift
> registers) - the outputs aren't  binary and you only get (2^n)-1 states (all
> zeros aren't valid), but these are basically shift registers with an xor
> feedback term and they use the fast carry logic. Maybe you can get software
> to do the reverse conversion if that is not in the critical path. Search
> Xilinx website for LSFRs.
> .

I disagree ( and I am the one who wrote the Xilinx app note on LFSRs.  :-)
LFSRs are the fastest synchronous counters, since they do NOT use the carry
chain, but just an XNOR feedback. (XNOR makes all-zero legal, but skips
all-ones, a better choice.) There is even a fairly simple trick to make an LFSR
go through all possible states.
LFSRs were more popular before Xilinx and Altera incorporated fast (ripple-)
carry logic in their FPGAs.

The counter that resolves the highest frequency is a simple ripple counter,
where only one flip-flop has to toggle at the max rate. I built a 420 MHz
BCD-ripple counter 3 years ago, and will soon try to do an even GHz in
Virtex-II.
Obviously, there is a ripple delay, so that you have to wait "awhile" before
you strobe the result into anything.

BTW, the LFSR is also the champion high-power consumption counter, with
statistically 50% of its flip-flops changing state on every clock tick.
Synchronous binary is much better, and ripple binary is best.

Peter Alfke, Xilinx Applications


Article: 28171
Subject: Re: Question about programming xcv100
From: longwayhome@my-deja.com
Date: Sun, 24 Dec 2000 00:29:06 GMT
Links: << >>  << T >>  << A >>
In article <3A45264E.F4FBE995@xilinx.com>,
  peter.alfke@xilinx.com wrote:
> David,
> let me talk you out of what you seem to be trying.

Oh dear :-)

> Xilinx used to make the XC6200 chip that did not have multiple outputs
> able to drive the same line, so it was bullet-proof, and it became the
> darling of experimenters like you.
> Unfortunately, XC6200 did not find a home in commercial applications,
so
> we stopped making it.

Yes, someone recommended me to get one of those chips, however I
learned you weren't producing them anymore (and didn't know why they
had become so 'legendary' in this use anyway).

> If you want to put evolving bitstreams on any Xilinx ( or Altera or
Atmel)
> FPGAs, don't do it !

What I was planning on doing (correct me if i'm way out of line here,
which is fairly possible) was taking each 'cell' on the fpga (in a
given area, for example an area of 20 x 20 cells) then having some
simple rules which i'd follow, deciding what the purpose of a given
cell was to be (within the rules, eg only one output to drive a given
line) then i'd take this meta design (arrived at through an evolving
algorithm) convert it to the bitstreams and pass the bitstream to the
chip using the xsload (comes with the Xess cdrom) where it would be
evaluated. However i'd need to find out what each bit for a cell
specified which I could then use to transfer my meta design to a
bitstream - is it possible to get this info [i'm just a hobbyist, no
danger of me seeking to get any competitive advantage over xilinx i can
assure you :-)]

I didn't actually want to treat the bitstreams themselves as a piece
of 'dna' to mutate/breed etc although now that you've mentioned that
idea an XC6200 board would be a nice thing to have (if xilinx have any
such boards lying around destined for wastage... :-)

Thanks for your warning though. Can you can help with that cell
programming info, or suggest any other way of approaching this
problem ? (i'm _really_ desperate to try this evolving hardware
thing...)

David


Sent via Deja.com
http://www.deja.com/

Article: 28172
Subject: Re: ActiveHDL 4.1?
From: Hien Pham <hienpham@my-deja.com>
Date: Sun, 24 Dec 2000 04:50:55 GMT
Links: << >>  << T >>  << A >>
How does this Aldec Active HDL compare to Mentor's FPGA Advantage 4.0 ?

FPGA Advantage is quite nice as well.

In article <sWx%5.73920$58.9187280@typhoon.tampabay.rr.com>,
  "S. Ramirez" <sramirez@deleet.cfl.rr.com> wrote:
> Swift,
>     I have and use Aldec's Active-HDL 4.1 simulator for all Verilog
and VHDL
> designs, except when a client company insists that I use their
simulator
> tool.  Some of these tools have sign-off capability; however, I don't
need
> anyone signing off on my FPGAs!
>     Of all of the simulators, it has a great Windows GUI, and it
seems to be
> the only simulator with a Windows GUI designed from the ground up.
Other
> simulators seem to be "Windows-like," i.e., they seem to be adapted
from
> Unix or DOS based designs.
>      I have used it to do simple to complex designs with relatively
little
> problem.  I had a problem once with 4.0, and their support department
jumped
> right on it.  Problems are normal for all products, it seems, and the
true
> differentiator, is tech support.
>      You will not go wrong with Active-HDL 4.1 and Synplicity.  Those
are
> the tools I use, and they are great!
> Simon Ramirez, Consultant
> Synchronous Design, Inc.
> Oviedo, FL, USA
>
> "Swift" <jboss@wxs.nl> wrote in message
> news:91iv1c$1jh9f$1@reader2.wxs.nl...
> > Does anyone use this tool for simulating VHDL-stuff for a FPGA?
What's
> your
> > opinion? Any other suggestions? We need a tool only to simulate a
> > VHDL-design. We already use Synplicity to synthesize.
> >
> > THX,
> >
> > JB
>
>

--
Hien Pham
San Francisco, CA


Sent via Deja.com
http://www.deja.com/

Article: 28173
Subject: Re: Question about programming xcv100
From: Muzaffer Kal <muzaffer@dspia.com>
Date: Sun, 24 Dec 2000 07:04:58 GMT
Links: << >>  << T >>  << A >>
On Sun, 24 Dec 2000 00:29:06 GMT, longwayhome@my-deja.com wrote:
>Thanks for your warning though. Can you can help with that cell
>programming info, or suggest any other way of approaching this
>problem ? (i'm _really_ desperate to try this evolving hardware
>thing...)

I have an idea on on this. I think it should be possible to write an
EDF as the output of your genetic algorithm and go through the P&R
(you can use the command line tools for full automation). If you can
also generate the placement with your tool (actually the placement is
already fixed; you just need to generate the behaviour of each
individual LUT) the P&R should be quick. This might prevent you from
programming the FPGA to reprogram itself, i.e. you can't put the
growth algorithm into the FPGA and get it to reprogram itself. The
pc/workstation has to be in the feedback loop. I think this is a much
easier project than reverse-engineering the bit file.

hope this helps,

Muzaffer

FPGA DSP Consulting
http://www.dspia.com

Article: 28174
Subject: Re: Verilog or VHDL
From: kenkovaa@gamma.hut.fi (Kim Gunnar Enkovaara)
Date: 24 Dec 2000 08:00:58 GMT
Links: << >>  << T >>  << A >>
On Mon, 18 Dec 2000 02:39:05 GMT, bobdittmar@my-deja.com wrote:

>When selecting which one is "better" you should also keep in
>mind what your verification strategy is. I find verilog to be good
>for doing behavioral modeling of my test objects : processor bus
>models, data packet generators/monitors etc that reside in the
>testbench and are "wired" to the FPGA under test.

Without PLI Verilog is quite difficult language to use for really
complex behavioral models. The Verilog language itself is quite
restricted, for example file i/o is poor compared to VHDL (altough
it's easier to use in Verilog). Also without real data types complex
behavioral models are not fun thing to do.

For verification I would suggest new verification languages (Vera,
e). I have used Vera quite extensivly and wouldn't go back easily to
HDL languages in testbenches. I can't even think of writing 30-40k
lines of complex TB code in some HDL language :) Object orientation
speeds up the TB-design considerably. 

>I'm not real VHDL literate but I have not seen this same testability
>in VHDL.

You should propably read some VHDL book. VHDL was originally designed
for system modeling and is quite strong language in modelling. Only
small part of the language is used in synthesizable models.

-- 
=============================================================================
Mr. Kim Enkovaara   | kim.enkovaara@iki.fi | Microelectronic Riemannian
Iirislahdentie 47 E | IRC: embo            | curved-space fault in
02230 Espoo,Finland |                      | write-only file system



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