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 128725

Article: 128725
Subject: Re: Scaling data
From: Anuja <thakkar.anuja@gmail.com>
Date: Tue, 5 Feb 2008 06:13:26 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 4, 10:01=A0am, "RCIngham" <robert.ing...@gmail.com> wrote:
> >Hello All,
>
> >I am using the UNIFORM procedure in VHDL to generate random numbers.
> >UNIFORM generates random numbers in the range 0.1 to 0.99999. I wish
> >to generate random signed and unsigned numbers of variable
> >widths(integer range). I would like to get some ideas on how I should
> >scale this data? Right now, when i convert the real output from real
> >to integer to signed, it just gives me an output of wither 0 or 1 .
> >Your comments would be appreciated
>
> >Thank you
>
> Actually it returns reals in the range 0.0 to 1.0 (exclusive), that is it
> can return 0.0, but not 1.0.
>
> As a previous reply states, you need to multiply the returned value by a
> (real type) scaling factor before conversion to unsigned, and remember to
> offset if converting to signed.

Thank you very much everyone.

Article: 128726
Subject: Re: How to optimize my design area to fit?
From: filter001@desinformation.de
Date: Tue, 5 Feb 2008 06:14:41 -0800 (PST)
Links: << >>  << T >>  << A >>
On 5 Feb., 14:17, hilo_p...@hotmail.com wrote:
> Hi all,
>
> I am currently building a Digital Down Converter on Xilinx System
> Generator 9.1 platform which unfortunately overshot resources provided
> by mt target Virtex 4 chip by 400%. Is there any optimization way to
> shrink it down.?

Yes, suitable optimization functions can only be found in some minds
of engineers thesedays. I would be suprised if anybody finds a set of
switches that "optimize this DDC design by 400% in area".

Article: 128727
Subject: Re: A way to limit the data path delay
From: Dunstan Power <dunstanp@bytesnap.co.uk>
Date: Tue, 05 Feb 2008 14:19:11 +0000
Links: << >>  << T >>  << A >>
LilacSkin wrote:
> Hello,
> 
> I have a problem with apparently no issue.
> 
> I use a V5 and I have a problem with the data path delay of a net.
> This net is used everywhere in my design and particulary in fixed
> blocs.
> The fanout is reduced to the maximum and I put a maxdelay constraint
> on it.
> The syntesis options are configured for speed.
> 
> Anybody have an idea to reduce this delay ?
> 
> Tk.
> 
There are two normal ways to fix this problem. Firstly to add 
pipe-lining stages (series flip-flops) in, accepting that this puts a 
clock delay on the signal. The delay may or may not matter depending on 
your design.

Alternatively, replicating the logic would help to reduce the fan-out. 
The latter is something that your synthesis tool may try. This depends 
on the tool settings, but you should be able to see if it has by looking 
at the synthesis reports. If you do it manually in the RTL you may be 
able to do it in a more transparent and controllable and therefore 
maintainable manner.

Regards,

Dunstan Power

ByteSnap Design Ltd,
Web:	www.bytesnap.co.uk

Article: 128728
Subject: Re: Possible CRC error on XC3S400 - now what?
From: Gabor <gabor@alacron.com>
Date: Tue, 5 Feb 2008 06:19:33 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 5, 9:56 am, Michael Meeuwisse
<mickeymeeuw@nospamplease_thesearchcompanywithcolorfulletters'emailservice.com>
wrote:
> Hi,
>
>
>
> Sky46...@trline5.org wrote:
> > Michael Meeuwisse <mickeymeeuw@nospamplease_thesearchcompanywithcolorfulletters'emailservice.com> wrote:
>
> >>I'm trying to configure a Xilinx Spartan 3 s400 through JTAG in a new
> >>prototype but I'm getting some weird results back while programming it.
> >>I hope somebody with more experience can help me out.
>
> >>The fpga is the 2nd device in a chain of 3 devices, of which the third a
> >>XC95144XL is which can be programmed succesfully. I assume therefore
> >>that there are acceptable noise levels on the bus and bus speed
> >>(currently at about ~1.2MHz - depends a bit on how fast the programmer
> >>can handle incoming data but not faster than that) is Ok.
>
> >  * Check power for any dips or transients.
>
> My VccAux seems to be 2.34V, this is supplied by a lm1086-2.5 so I don't
> really know what's causing this (it's just below the minimum required,
> isn't it?) or how I can fix it. Vcco is 3.34V and VccInt is 1.20V.
>
> >  * Connect directly with a parallell port jtag adapter.
> >    Like this:http://www.xilinx.com/support/programr/jtag_cable.pdf
>
> >    (And only try the USB approch once it confirmed to work)
>
> The thing is, the programmer is embedded on the board itself so
> connecting a different programmer would require me to start cutting pcb
> traces.
>
> >  * Lower the clocking frequency, try 50 kHz.
>
> Didn't seem to help. Afaik there's no minimum clock so I even tried it
> at ~100Hz (which takes forever btw, in case you never tried it) but it
> still failed.
>
> >  * Double check all pins related to configuration (DONE, M0,M1,M2, INIT_B,
> >    CCLK, etc)
>
> M[2:0] are all tied to ground, and changing this would again require
> some force so I'd rather not. This shouldn't matter afaik, since you can
> always program using JTAG anyway, right? Likewise, when configuring
> using JTAG it doesn't matter what CCLK is, does it? I mentioned the
> state of INIT_B, PROG_B and DONE earlier.
>
> >  * You could connect pins to the fpga DIN etc.. back to your PC to verify your
> >    fpga actually get the data you expect.
>
> Would data pushed in through JTAG appear on DIN? I could write something
> that checks TDO but I'm told the spartan spits out zeroes or other
> nonsense when I'm shifting data in.
>
> Thorsten Trenz wrote:
>
>  > Hi,
>  >
>  > Try to switch the modepins to JTAG only. Do you use a PC3 clone? There
>  > seems to be some problems in certain impact versions with PC3 and S3 if
>  > the chip is not in JTAG only mode.
>
> The programmer is an FTDI FT2232 using an homebrew XSVF parser. I
> believe I've got all the bugs worked out of the software since
> programming the CPLD goes without a problem.
>
> Cheers,
>
> Mikehttp://projectvga.org

You didn't say what the first device in the chain was.  There are
known
issues when placing a PlatformFlash (XCF02S for instance) in front of
a Spartan device wired up for master serial configuration mode.

Do you have a pullup on the DONE pin?  If not have you checked the
"Drive Done pin high" option in bitgen?

Are you providing enough clocks at the end of the bitstream load to
start up the device (again look at where DONE is supposed to go high
in the bitgen options)?

That's all I can think of.

By the way if you are using an XFCxxS device in front of your FPGA,
try erasing it to see if that helps the JTAG load.

Regards,
Gabor

Article: 128729
Subject: Re: How to optimize my design area to fit?
From: Dunstan Power <dunstanp@bytesnap.co.uk>
Date: Tue, 05 Feb 2008 14:28:11 +0000
Links: << >>  << T >>  << A >>
hilo_pupu@hotmail.com wrote:
> Hi all,
> 
> I am currently building a Digital Down Converter on Xilinx System
> Generator 9.1 platform which unfortunately overshot resources provided
> by mt target Virtex 4 chip by 400%. Is there any optimization way to
> shrink it down.?

That is a bad overshoot ! The first thing that I would look at is memory 
usage ie are you using block RAMs ? Make sure you don't have some 
memories being turning into flops ! I have had some versions of 
Synplicity do this on pretty benign code, where previous versions 
synthesized the memory as Block RAM. Look at your synthesis report.

Other things you can do is logic sharing ie use one block to serve 
multiple parts of the design by clocking it at a higher frequency than 
the rest of the design and multiplex the input and outputs.

You need to get a handle on which the biggest blocks are and tackle 
those first if they are not 3rd party IP.

Ultimately You may have to face that your target FPGA is far too small 
of course. You wouldn't be the first one ...

Regards

-- 

Dunstan Power

ByteSnap Design Ltd,
Web:	www.bytesnap.co.uk

Article: 128730
Subject: Re: Possible CRC error on XC3S400 - now what?
From: Michael Meeuwisse <mickeymeeuw@nospamplease_thesearchcompanywithcolorfulletters'emailservice.com>
Date: Tue, 05 Feb 2008 14:56:22 +0000
Links: << >>  << T >>  << A >>

Hi,

Sky465nm@trline5.org wrote:
> Michael Meeuwisse <mickeymeeuw@nospamplease_thesearchcompanywithcolorfulletters'emailservice.com> wrote:
> 
>>I'm trying to configure a Xilinx Spartan 3 s400 through JTAG in a new 
>>prototype but I'm getting some weird results back while programming it. 
>>I hope somebody with more experience can help me out.
> 
> 
>>The fpga is the 2nd device in a chain of 3 devices, of which the third a 
>>XC95144XL is which can be programmed succesfully. I assume therefore 
>>that there are acceptable noise levels on the bus and bus speed 
>>(currently at about ~1.2MHz - depends a bit on how fast the programmer 
>>can handle incoming data but not faster than that) is Ok.
> 
> 
>  * Check power for any dips or transients.

My VccAux seems to be 2.34V, this is supplied by a lm1086-2.5 so I don't 
really know what's causing this (it's just below the minimum required, 
isn't it?) or how I can fix it. Vcco is 3.34V and VccInt is 1.20V.

>  * Connect directly with a parallell port jtag adapter.
>    Like this: http://www.xilinx.com/support/programr/jtag_cable.pdf
> 
>    (And only try the USB approch once it confirmed to work)

The thing is, the programmer is embedded on the board itself so 
connecting a different programmer would require me to start cutting pcb 
traces.

>  * Lower the clocking frequency, try 50 kHz.    

Didn't seem to help. Afaik there's no minimum clock so I even tried it 
at ~100Hz (which takes forever btw, in case you never tried it) but it 
still failed.

>  * Double check all pins related to configuration (DONE, M0,M1,M2, INIT_B,
>    CCLK, etc)

M[2:0] are all tied to ground, and changing this would again require 
some force so I'd rather not. This shouldn't matter afaik, since you can 
always program using JTAG anyway, right? Likewise, when configuring 
using JTAG it doesn't matter what CCLK is, does it? I mentioned the 
state of INIT_B, PROG_B and DONE earlier.

>  * You could connect pins to the fpga DIN etc.. back to your PC to verify your
>    fpga actually get the data you expect.
> 

Would data pushed in through JTAG appear on DIN? I could write something 
that checks TDO but I'm told the spartan spits out zeroes or other 
nonsense when I'm shifting data in.

Thorsten Trenz wrote:
 > Hi,
 >
 > Try to switch the modepins to JTAG only. Do you use a PC3 clone? There
 > seems to be some problems in certain impact versions with PC3 and S3 if
 > the chip is not in JTAG only mode.

The programmer is an FTDI FT2232 using an homebrew XSVF parser. I 
believe I've got all the bugs worked out of the software since 
programming the CPLD goes without a problem.

Cheers,

Mike
http://projectvga.org

Article: 128731
Subject: Re: A way to limit the data path delay
From: LilacSkin <lpaulo07@iseb.fr>
Date: Tue, 5 Feb 2008 06:57:15 -0800 (PST)
Links: << >>  << T >>  << A >>
On 5 f=E9v, 15:19, Dunstan Power <dunst...@bytesnap.co.uk> wrote:
> LilacSkin wrote:
> > Hello,
>
> > I have a problem with apparently no issue.
>
> > I use a V5 and I have a problem with the data path delay of a net.
> > This net is used everywhere in my design and particulary in fixed
> > blocs.
> > The fanout is reduced to the maximum and I put a maxdelay constraint
> > on it.
> > The syntesis options are configured for speed.
>
> > Anybody have an idea to reduce this delay ?
>
> > Tk.
>
> There are two normal ways to fix this problem. Firstly to add
> pipe-lining stages (series flip-flops) in, accepting that this puts a
> clock delay on the signal. The delay may or may not matter depending on
> your design.
>
> Alternatively, replicating the logic would help to reduce the fan-out.
> The latter is something that your synthesis tool may try. This depends
> on the tool settings, but you should be able to see if it has by looking
> at the synthesis reports. If you do it manually in the RTL you may be
> able to do it in a more transparent and controllable and therefore
> maintainable manner.
>
> Regards,
>
> Dunstan Power
>
> ByteSnap Design Ltd,
> Web:    www.bytesnap.co.uk

I cannot change the logic because this net is used in an IP.
In a virtexII there were low skew lines, there is sometning like that
in a v5 ??

Tk.

Article: 128732
Subject: Re: How to optimize my design area to fit?
From: Chris Maryan <kmaryan@gmail.com>
Date: Tue, 5 Feb 2008 07:08:45 -0800 (PST)
Links: << >>  << T >>  << A >>
Not knowing anything about the system generator, but knowing a thing
or two about DDC, my suspicion is that you have run into one of two
issues (assuming this is the usual DDS-CIC-FIR type downconverter):
- Your sin/cos LUT is not in RAM or has more entries than needed. If
you want, I can send you a matlab script that will show you the
tradeoff between various LUT table lengths, wordlengths vs. noise that
may help you design this better.
- Your FIR filter is attempting to do many parallel multiplies, this
is very resource intensive. One of the reasons for downsampling is
that you can reduce the data rate in the FIR and not have 20 parallel
multipliers in a 20 tap FIR, but rather do them sequentially in
between new samples coming into the FIR stage.

Chris

Article: 128733
Subject: GCLK overmapped
From: markmcmahon@hotmail.com
Date: Tue, 5 Feb 2008 07:23:48 -0800 (PST)
Links: << >>  << T >>  << A >>
Hello,

From searching, I see that others have had this same problem, but the
solutions were vague and old (2002).  I'm using XPS 8.1 with Spartan
IIE 600 and I'm trying to bring a couple of signals from a peripheral
to a pin, but XPS automatically assumes that they are clocks, so it
uses a GCLK which results in the error:

"Number of GCLKs:	5 out of 4	125% (OVERMAPPED)".

How can I find out which signals it has routed as GCLKs?
How can I reduce the number of GCLKs used?
How can I manually assign GCLKs to the signals I want, without XPS
doing it automatically?

I've tried passing the signals through an OBUF in the wrapper of my
peripheral, but that results in an "illegal buffer" error.

Thanks for your help.

Article: 128734
Subject: Re: Possible CRC error on XC3S400 - now what?
From: Michael Meeuwisse <mickeymeeuw@nospamplease_thesearchcompanywithcolorfulletters'emailservice.com>
Date: Tue, 05 Feb 2008 15:43:27 +0000
Links: << >>  << T >>  << A >>


Gabor wrote:
> On Feb 5, 9:56 am, Michael Meeuwisse
> <mickeymeeuw@nospamplease_thesearchcompanywithcolorfulletters'emailservice.com>
> wrote:
> 
>>Hi,
>>
>>
>>
>>Sky46...@trline5.org wrote:
>>
>>>Michael Meeuwisse <mickeymeeuw@nospamplease_thesearchcompanywithcolorfulletters'emailservice.com> wrote:
>>
>>>>I'm trying to configure a Xilinx Spartan 3 s400 through JTAG in a new
>>>>prototype but I'm getting some weird results back while programming it.
>>>>I hope somebody with more experience can help me out.
>>
>>>>The fpga is the 2nd device in a chain of 3 devices, of which the third a
>>>>XC95144XL is which can be programmed succesfully. I assume therefore
>>>>that there are acceptable noise levels on the bus and bus speed
>>>>(currently at about ~1.2MHz - depends a bit on how fast the programmer
>>>>can handle incoming data but not faster than that) is Ok.
>>
>>> * Check power for any dips or transients.
>>
>>My VccAux seems to be 2.34V, this is supplied by a lm1086-2.5 so I don't
>>really know what's causing this (it's just below the minimum required,
>>isn't it?) or how I can fix it. Vcco is 3.34V and VccInt is 1.20V.
>>
>>
>>> * Connect directly with a parallell port jtag adapter.
>>>   Like this:http://www.xilinx.com/support/programr/jtag_cable.pdf
>>
>>>   (And only try the USB approch once it confirmed to work)
>>
>>The thing is, the programmer is embedded on the board itself so
>>connecting a different programmer would require me to start cutting pcb
>>traces.
>>
>>
>>> * Lower the clocking frequency, try 50 kHz.
>>
>>Didn't seem to help. Afaik there's no minimum clock so I even tried it
>>at ~100Hz (which takes forever btw, in case you never tried it) but it
>>still failed.
>>
>>
>>> * Double check all pins related to configuration (DONE, M0,M1,M2, INIT_B,
>>>   CCLK, etc)
>>
>>M[2:0] are all tied to ground, and changing this would again require
>>some force so I'd rather not. This shouldn't matter afaik, since you can
>>always program using JTAG anyway, right? Likewise, when configuring
>>using JTAG it doesn't matter what CCLK is, does it? I mentioned the
>>state of INIT_B, PROG_B and DONE earlier.
>>
>>
>>> * You could connect pins to the fpga DIN etc.. back to your PC to verify your
>>>   fpga actually get the data you expect.
>>
>>Would data pushed in through JTAG appear on DIN? I could write something
>>that checks TDO but I'm told the spartan spits out zeroes or other
>>nonsense when I'm shifting data in.
>>
>>Thorsten Trenz wrote:
>>
>> > Hi,
>> >
>> > Try to switch the modepins to JTAG only. Do you use a PC3 clone? There
>> > seems to be some problems in certain impact versions with PC3 and S3 if
>> > the chip is not in JTAG only mode.
>>
>>The programmer is an FTDI FT2232 using an homebrew XSVF parser. I
>>believe I've got all the bugs worked out of the software since
>>programming the CPLD goes without a problem.
>>
>>Cheers,
>>
>>Mikehttp://projectvga.org
> 
> 
> You didn't say what the first device in the chain was.  There are
> known
> issues when placing a PlatformFlash (XCF02S for instance) in front of
> a Spartan device wired up for master serial configuration mode.
> 

Yeah sorry, it's a XCF04S. I've got some other issues with that one 
however, it seems that is has some dead banks which is why I'm trying to 
program the fpga directly in the first place. As far as I can tell these 
two problems are unrelated.

> Do you have a pullup on the DONE pin?  If not have you checked the
> "Drive Done pin high" option in bitgen?
> 

No, no external pull up. I've set "Configuration pin done" to Float and 
checked "Drive done pin high" as suggested by table 2.6 of ug332.

> Are you providing enough clocks at the end of the bitstream load to
> start up the device (again look at where DONE is supposed to go high
> in the bitgen options)?
> 

I think so, I've tried programming the CPLD after I attempted to program 
the FPGA which should provide plenty of clock cycles, but it didn't 
change anything.

> That's all I can think of.
> 
> By the way if you are using an XFCxxS device in front of your FPGA,
> try erasing it to see if that helps the JTAG load.
> 
> Regards,
> Gabor

As it turns out, the LM1086-2.5 needs a minimum of 4V and I'm only 
giving it 3.3V so that might be cause of some of the trouble - it 
certainly explains why my VccAux is only ~2.3V. I'm going to fix that 
now and hopefully it'll help.

Cheers,

Mike
http://projectvga.org

Article: 128735
Subject: Re: Minimum Oscillator Frequency
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 5 Feb 2008 15:53:20 -0000
Links: << >>  << T >>  << A >>
"Dunstan Power" <dunstanp@bytesnap.co.uk> wrote in message 
news:13qgr82q2bdc6de@corp.supernews.com...
>
> You are right that DCMs have minimum clock freq restrictions (eg 24MHz in 
> V5),

Hi Dunstan,
Indeed, he is right, but I think you may not be. To be technically correct, 
(the best kind of correct!) if you use only the DFS output, FCLKINLFFXMSMIN 
is 1 MHz.
Read DS202, tables 50, 51. I couldn't find 24MHz anywhere, are you thinking 
of a different family? V5 MS mode apparently has a minimum of 32MHz, MR mode 
19MHz.
Cheers, Syms. 



Article: 128736
Subject: Re: A video tutorial: The Xilinx FPGA Editor
From: eli.billauer@gmail.com
Date: Tue, 5 Feb 2008 08:03:22 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 5, 12:23=A0am, Daniel Koethe <dkoe...@nospam-web.de> wrote:
> I want also
> know if there is everywhere a Documentation or a Howto about the FPGA
> Editor.

Well, I've been looking for some docs about the Editor every now and
then myself, but couldn't find anything instructive. So I suppose it's
pretty undocumented, except for the Help from within the application
itself.

    Eli

Article: 128737
Subject: New leonardo spectrum version has license errors
From: robquigley@gmail.com
Date: Tue, 5 Feb 2008 08:18:25 -0800 (PST)
Links: << >>  << T >>  << A >>
Hey everyone,

Just wonderting if anyone else has upgraded Leonardo Spectrum in a
while. I went from a (very) old version 2003b_65 to 2007a_37 and now
I'm getting erros when it tries to load libraries adn such.

Apparently the licenses known as ls3..... are now leospec3.... and the
former was for use with a MOdeltech daemon but the latter newer
versions are for use with a Mgcld daemon. I got that last bit from the
Mentor website: https://origin-www.mentor.com/supportnet/news/hdl_license_features.html#leo

but it doesnt say how or what I have to update to change this. I have
the leospec3.... licenses but just cant seem to get Leonardo Spectrum
to look for them! :-S


Ayone else have this issue?

Oh errors im getting are like thos included below:

Security Error -1: Checkout of "ls3_xi5" failed - Licensing checkout
error with feature ls3_xi_pkg. (Error code -97.)

Thanx for any help and happy pancake tuesday!!!!!




Rob.

Article: 128738
Subject: Re: Possible CRC error on XC3S400 - now what?
From: Sky465nm@trline5.org
Date: Tue, 5 Feb 2008 17:26:21 +0100 (CET)
Links: << >>  << T >>  << A >>
>>  * Check power for any dips or transients.

>My VccAux seems to be 2.34V, this is supplied by a lm1086-2.5 so I don't 
>really know what's causing this (it's just below the minimum required, 
>isn't it?) or how I can fix it. Vcco is 3.34V and VccInt is 1.20V.

XC3S400-PQ208
  http://direct.xilinx.com/bvdocs/publications/ds099.pdf (t31 p58/208)
          Min    Nom    Max
  Vccint  1.140  1.200  1.260
  Vccaux  2.375  2.500  2.625
  Vcco    1.140  -      3.450

LM1086-2.5
  http://users.ece.utexas.edu/~valvano/Datasheets/LM1086.pdf
          Min    Typ   Max
    Vout  2.450  2.50  2.525   (Vin=4-18V Ifull)

  Current limit:  Min=1.5A Typ=2.7A  at Vin=8V

Your Vcco regulator uses "3V3" for Vin with a 10uF capacitor on each input
and output.
"3V3" comes from S53, S39, S33, S27, S21, C25, C31, C36, C41, C43, C54 on
the PCI connector (CON1).
(Schematic: http://wacco.mveas.com/img/schema1d.png)

So the Vin of the 2.5V regulator is not enough.

Also there's the issue of voltage ramp time upon startup.
  Vcco   2000 us
  Vccaux    - us  (no requirement)
  Vccint  500 us
  (p57 Table 29 Power voltage ramp time requirements)

So you might need to check Vccint vs Vccaux. The Vccaux should be powered
before Vccint, but it's not that sensitive (or?). (see p53)

Check that your oscillator does have proper power. And outputs a correct
waveform at the XC3S400 input (Bank5 GCLK2, P76).
(LVTTL 0.8 - 2.0 swing + flanks)

>>  * Connect directly with a parallell port jtag adapter.
>>    Like this: http://www.xilinx.com/support/programr/jtag_cable.pdf
>>    (And only try the USB approch once it confirmed to work)

>The thing is, the programmer is embedded on the board itself so 
>connecting a different programmer would require me to start cutting pcb 
>traces.

Measure the output of your onboard usb programmer that it does what you
expect it to do. Ie feedback it's TDO to your parallell port.
If this fails, try the cut traces approach and solder some wires so you can
change programmer at will.

Also use program directly via JTAG mode to start with, only when that works
try eeprom. The first bitstream ("program") should be something simple like
pulsing a LED.

(604-00033G-ND  IC FTDI2232L USB/SERIAL 48-LQFP)

Scan chain (reverse order?):
  FTDI2232L - XC95144XL - XC3S400 - XCF01S - FTDI2232L

>>  * Lower the clocking frequency, try 50 kHz.    

>Didn't seem to help. Afaik there's no minimum clock so I even tried it 
>at ~100Hz (which takes forever btw, in case you never tried it) but it 
>still failed.

Verify bitstream at TDI+TCK?

{M0,M1,M2} = 3'b000			(ds099 p45 for mode table)

So configuration mode is master serial. Thus CCLK+DIN is the ones that
dictates programming. Setting M0=1, M1=0, M2=1 gives you jtag programming
mode. Which might make life easier in the beginning. It's also the mode
that is smoother to use when developing.

>>  * Double check all pins related to configuration (DONE, M0,M1,M2, INIT_B,
>>    CCLK, etc)

>M[2:0] are all tied to ground, and changing this would again require 
>some force so I'd rather not. This shouldn't matter afaik, since you can 
>always program using JTAG anyway, right? Likewise, when configuring 
>using JTAG it doesn't matter what CCLK is, does it? I mentioned the 
>state of INIT_B, PROG_B and DONE earlier.

M[2:0] = 000 => Master serial mode according to datasheet ds099 page 45.
So CCLK will matter. Btw, check if CCLK (2.5V) does output a proper waveform
at the eeprom input (Pin3 CLK). And that eeprom output is correct at the fpga.

Btw, notice that CCLK is 2.5V, and eeprom output is 3.3V

Signals:
INIT_B    Shall go high after memory is cleared. And shall not be tied low.
PROG_B    Goes high?
DONE      Goes high after configuration is complete.
HSWAP_EN  Is tied low in your schematic => Pullup resistors enabled on all
          pins not activly involved in the configuration process.
          Check that no pullup'ed pin interfere with the configuration process.
(ds099 p101)

You might use these to find out what's going on.

>>  * You could connect pins to the fpga DIN etc.. back to your PC to verify your
>>    fpga actually get the data you expect.

>Would data pushed in through JTAG appear on DIN? I could write something 
>that checks TDO but I'm told the spartan spits out zeroes or other 
>nonsense when I'm shifting data in.

My idea was to attach a wire directly to TDI/TDO + TCK back into an INPUT pin
of the parallell port to verify data.

>Thorsten Trenz wrote:
> > Hi,
> >
> > Try to switch the modepins to JTAG only. Do you use a PC3 clone? There
> > seems to be some problems in certain impact versions with PC3 and S3 if
> > the chip is not in JTAG only mode.

>The programmer is an FTDI FT2232 using an homebrew XSVF parser. I 
>believe I've got all the bugs worked out of the software since 
>programming the CPLD goes without a problem.

Verify board connections -> Power -> Clocks -> Other.

I think also that if you try to program:
  Onboard USB -> XCF01S eeprom
  eeprom -> FPGA

  You add more steps that may fail.
  Also you could try to manually read if the contents of the XCF01S is what
  you expect.

>it's a XCF04S. I've got some other issues with that one
>however, it seems that is has some dead banks which is why I'm trying to
>program the fpga directly in the first place. As far as I can tell these
>two problems are unrelated.

So you need to alter M[0:2] pins to 1-0-1 (ds099 p45).
And according to table 26 (ds099 p45) you need at least an XCF02S.
So schematic is contradictive.. :)

Your schematic would be easier to follow if you added consistent chip
identifications ie Ux XC3S400 etc..

Also soldering pads for debug fixes could be something to have in mind for
later revisions. Assume failure ;)


Article: 128739
Subject: Re: Bitstream verification through readback
From: Sky465nm@trline5.org
Date: Tue, 5 Feb 2008 17:31:02 +0100 (CET)
Links: << >>  << T >>  << A >>
maverick <sheikh.m.farhan@gmail.com> wrote:
>Hi,
>i need to know is it possible to readback and verify the loaded
>configuration in the FPGA after the GSR is deasserted and the FPGA is
>up and running with the loaded configuration? I am suspecting that due
>to power requirement of my application, the FPGA loses its
>configuration when the current demand increases ( HDD is connected to
>the FPGA board, when the FPGA talks to the HDD through SATA
>controller, the current goes up from  .8 Amp to 1.7 Amps)and the FPGA
>stops working in the expected manner.

Try separate power supplies for the FPGA and HDD ..?


Article: 128740
Subject: Re: Server configuration for Virtex5
From: Goli <togoli@gmail.com>
Date: Tue, 5 Feb 2008 08:38:31 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 5, 6:03 pm, Sky46...@trline5.org wrote:
> >The synthesis tools currently run as a single threaded process, and
> >therefore dual and quad core CPUs have a limited effect on
> >performance. I run the tools on my dual core desktop and the main
> >benefit of dual core for me is that I can perform other tasks while
> >the tools are crunching away on one of the CPUs, on my previous single
> >core machine it was pretty much unusable.
> >Apart from having at least one fast CPU you will also benefit greatly
> >from having a large amount of high bandwidth memory (<=2GB). Make sure
> >it is dual channel and some high frequency DDR variant.
> >I'm not sure what impact fast hard drives make, since (as far as i
> >know) as long as you don't run out of memory that's where the number
> >crunching is performed.
>
> The factors seems to look like this:
>   * Don't bother with more than one core.
>   * L2 cache is really good (L1 doesn't hurt).
>   * Fast memory bus (FSB speed).
>   * Fast dram chips (DDR2 >600 MHz etc).
>   * 64 bit over 32bit.
>   * CPU frequency.
>
> So you should get fast memory primarly, and secondarly look at cpu frequency.

Hi,
Rob,
sky46

Thanks a lot for your inputs.

--
Goli

Article: 128741
Subject: Re: Loading the design from Compact Flash...
From: Xesium <amirhossein.gholamipour@gmail.com>
Date: Tue, 5 Feb 2008 09:13:24 -0800 (PST)
Links: << >>  << T >>  << A >>
Dave,
Thanks so much. Actually removing -target mdm worked!
I feel dumb to have spent weeks trying to fix this issue! But at least
it is working now!

Thanks a lot again,

Amir

On Feb 4, 11:26 pm, David <simianfe...@gmail.com> wrote:
> > I actually tried this command:
> > $ xmd -tcl genace.tcl -jprog -hw implementation/download.bit -board
> > ml310 -target mdm -elf timer_test/executable.elf -ace system.ace
>
> > My software code is supposed to write something to hyperterminal
> > through RS232 port and I have in fact populated the local BRAMs with
> > the data and instructions of my software code and download.bit should
> > contain that information (I tried commands with and without -elf
> > timer_test/executable.elf).
>
> Did you try removing the "-target mdm" as well?  If your program is in
> bram it shouldn't be necessary.
>
> > Firstly I don't know why it is so, secondly I know no more convenient
> > way to make sure that my design is actually loaded and working (the
> > only way I found convenient is to write something to the output)!
>
> You could try a very simple design in ISE that just flashes a led or
> something and make an ace file from that.  That should at least tell
> you whether it is a problem with the systemAce or the microblaze.
>
> Also, re-reading your original post - you probably don't need the OPB
> SysAce controller unless you intend to write to the compact flash - it
> could be causing some conflict with the sysace chip if it's not set up
> properly.
>
> Cheers,
> Dave


Article: 128742
Subject: Sythesisable subset of VHDL
From: Gerry <Gerry@hotmail.com>
Date: Tue, 05 Feb 2008 17:29:55 +0000
Links: << >>  << T >>  << A >>
Hi

I have done some VHDL implementations that were successfully running on 
an FPGA. However, I still feel unsecure about what constructs so that 
the design is working in the end. I am using XST, they have some 
modelling advices for specific constructs. Are there any other sources
that could help me to improve my code?

Many thanks!

Article: 128743
Subject: Re: How to optimize my design area to fit?
From: John Retta <jretta@rtc-inc.com>
Date: Tue, 05 Feb 2008 10:35:03 -0700
Links: << >>  << T >>  << A >>
The resources of Xilinx FPGAs
   - BlkRAMSs
   - multipliers
   - LUTS
   - FFs
   - DCMs
all can be the first to max out.  You need to
look at your .mrp report to get an idea of which
resoures max'd out first.  Cutting back an implementation
by 75%, and still have identical functionallity sounds
pretty tough.

However, Basic Debug 101 should tell you to go back
to the core generator, and selectively enable/disable
certain features of your DDS so you can get an idea
of the resource size of each block element.  Then you
can explore whether parts of design might be reduced
in performance to give area reductions.  ie, the DSP
Slice in V4 contains multipliers that are 18x18.
You might want to choose tap coefficients 18 bits or less.
Otherwise multiple slices may be used for single multiply.

I think the FIR is usually the resource hog in the downconverter.
You might want to temporarily skip the DDS, and compile
the FIR with different attribute sizes to get an idea of
what the resource usage might be.

Good luck.

-- 

Regards,
John Retta
Owner and Designer
Retta Technical Consulting Inc.

Colorado Based Xilinx Consultant

phone : 303.926.0068
email : jretta@rtc-inc.com
web   :  www.rtc-inc.com

Article: 128744
Subject: Modelsim Warning
From: FPGA <FPGA.unknown@gmail.com>
Date: Tue, 5 Feb 2008 09:51:18 -0800 (PST)
Links: << >>  << T >>  << A >>
I am getting the following warning in Modelsim

# ** Warning: Design size of 10053 statements or 1 leaf instances
exceeds ModelSim PE Student Edition recommended capacity.
# Expect performance to be quite adversely affected.

When I run simulations, I do not see any waveforms and it just freezes
there forever. My design size if around 1000 lines. I do have other
vhdl files for other projects. I have Modelsim Student edition.

How do I fix this problem?

Thanks

Article: 128745
Subject: Re: Sythesisable subset of VHDL
From: "RCIngham" <robert.ingham@gmail.com>
Date: Tue, 05 Feb 2008 11:59:13 -0600
Links: << >>  << T >>  << A >>
>Hi
>
>I have done some VHDL implementations that were successfully running on 
>an FPGA. However, I still feel unsecure about what constructs so that 
>the design is working in the end. I am using XST, they have some 
>modelling advices for specific constructs. Are there any other sources
>that could help me to improve my code?
>
>Many thanks!
>
The definitive answer is to follow the synthesis interoperability subset
definded in IEEE 1076.6, but this is very restrictive, and you probably
cannot get hold of it without paying.

Altera, Xilinx, and Actel support very similar synthesisable subsets, so
if you follow the XST guidelines you will not go far wrong. Inferring
RAMs, ROMs, and some other technology-related constructs is where things
may diverge. Being technology independent is a worthy aim, but getting
your design working on the technology you are using now is the primary
goal.



Article: 128746
Subject: Re: MG Leonardo Synthesis Options
From: Mike Treseler <mike_treseler@comcast.net>
Date: Tue, 05 Feb 2008 11:09:16 -0800
Links: << >>  << T >>  << A >>
giorgos.puiklis@gmail.com wrote:

> 1. How can I see the exact functionality of the the cells Leonardo
> produces in its RTL Schematic, after reading my input HDL files?

These are just place holders for blocks of logic.
After place and route, they won't be recognizable.
Functionality is determined by your source code, not synthesis.

> 2. When I use the VHDL "block" statement, the synthesizer appears to
> completely neglect (in its RTL schematic) the blocks I asked for. It
> creates the same schematic it did before I entered the block-
> statements. Is there a way to make the synthesizer take into account
> block-statements?

The vhdl block statement is just a language scope limiter.
If I wanted a structural block I would make a separate entity.


        -- Mike Treseler

Article: 128747
Subject: Re: New leonardo spectrum version has license errors
From: Mike Treseler <mike_treseler@comcast.net>
Date: Tue, 05 Feb 2008 11:16:10 -0800
Links: << >>  << T >>  << A >>
robquigley@gmail.com wrote:

> Anyone else have this issue?

Yes. We updated the server to mgcld several years ago,
but I don't remember the details.
Call Mentor.

         -- Mike Treseler

Article: 128748
Subject: Re: Modelsim Warning
From: Mike Treseler <mike_treseler@comcast.net>
Date: Tue, 05 Feb 2008 11:20:43 -0800
Links: << >>  << T >>  << A >>
FPGA wrote:

> # ** Warning: Design size of 10053 statements or 1 leaf instances
> exceeds ModelSim PE Student Edition recommended capacity.
> # Expect performance to be quite adversely affected.

> How do I fix this problem?

Remove 53 lines or buy a license.

      -- Mike Treseler

Article: 128749
Subject: Re: GCLK overmapped
From: "Dwayne Dilbeck" <ddilbeck@yahoo.com>
Date: Tue, 5 Feb 2008 12:01:36 -0800
Links: << >>  << T >>  << A >>
This information is from ISE9.2i, Spartan 3e target.

> How can I find out which signals it has routed as GCLKs?
In the GUI, bring up the design summary.
Under "Design Overview"  in the Design summury window.  Click on "CLOCK 
REPORT"
If a clock is listed as beign in Resource BUFGMUX_*,  It is being assigned 
to GCLK.

> How can I reduce the number of GCLKs used?
I don't know.


> How can I manually assign GCLKs to the signals I want, without XPS
> doing it automatically?

Xilinx Constraint User Guide(P191 of 396)
(UCF)
INST "buf1" LOC=GCLKBUF1;




<markmcmahon@hotmail.com> wrote in message 
news:dba09492-1743-4a7f-a11f-53228ff01620@e10g2000prf.googlegroups.com...
> Hello,
>
> From searching, I see that others have had this same problem, but the
> solutions were vague and old (2002).  I'm using XPS 8.1 with Spartan
> IIE 600 and I'm trying to bring a couple of signals from a peripheral
> to a pin, but XPS automatically assumes that they are clocks, so it
> uses a GCLK which results in the error:
>
> "Number of GCLKs: 5 out of 4 125% (OVERMAPPED)".
>
 





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