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 139325

Article: 139325
Subject: Re: virtex-5 lvds termination issue?
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 26 Mar 2009 14:50:02 -0000
Links: << >>  << T >>  << A >>
One more thing, did you terminate the clock signal at the ADC clock 
receiver? The ADC doesn't have on board termination from what I see on the 
datasheet. 



Article: 139326
Subject: Re: Dynamic reconfiguration in Spartan 3
From: Jecel <jecel@merlintec.com>
Date: Thu, 26 Mar 2009 07:56:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 26, 2:22=A0am, Moazzam wrote:

> [...] =A0I don't think that there is any ICAP
> in Spartan-3 FPGA.

My impression is that the chip itself does have an ICAP block but that
there are problems with it do the Xilinx tools don't allow it to be
used. In any case, in practice it is not an option.

> The only available option is through the JTAG
> interface.

You could also use the slave parallel or serial programming modes by
connecting these ports to other FPGA pins that would could be accessed
by the Microblaze processor. The complication would be dealing with
the initial configuration, which would have to come through the same
port.

> I learnt from a post on this group that Spartan-3 may
> exhibit some glitchy behaviour during the process of dynamic
> reconfiguration, so it is not recommended for partially reconfigurable
> designs.

There is contradictory information about this on the web, so I don't
know what to think. This software tool handles partial reconfiguration
on both the Virtex II (and Pro) and the Spartan 3:

http://www.recobus.de/

-- Jecel

Article: 139327
Subject: Sysace_fread syntax probleme
From: mopra <mohitprakas@gmail.com>
Date: Thu, 26 Mar 2009 08:17:21 -0700 (PDT)
Links: << >>  << T >>  << A >>
Here is a sample code, I want to know what should I put in the third
line of code in place of X , to read 10 int data from a file stored on
sysace flash memory. It is assumed that int is 4 byte long. Should it
be 10 since there are 10 integer data, or should it be 40 since there
are 40 character data?? Please help


   int numread;
  unsigned int readBuffer[10]
  numread = sysace_fread((char*)readBuffer, 1, X , fptr);


Article: 139328
Subject: Re: Sysace_fread syntax probleme
From: Alan Fitch <alan.fitch@spamtrap.com>
Date: Thu, 26 Mar 2009 16:30:19 +0000
Links: << >>  << T >>  << A >>
mopra wrote:
> Here is a sample code, I want to know what should I put in the third
> line of code in place of X , to read 10 int data from a file stored on
> sysace flash memory. It is assumed that int is 4 byte long. Should it
> be 10 since there are 10 integer data, or should it be 40 since there
> are 40 character data?? Please help
> 
> 
>    int numread;
>   unsigned int readBuffer[10]
>   numread = sysace_fread((char*)readBuffer, 1, X , fptr);
> 

 From the EDK xilfatfs documentation

Parameters buffer is a pre allocated buffer that is passed in to this
procedure, and is used to return the characters read from the
device.

size is restricted to 1.

count is the number of characters to be read.

file is the file handle returned by sysace_fopen.

So it's the number of characters,

Alan

-- 
Alan Fitch
Senior Consultant

Doulos  Developing Design Know-how
VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project 
Services

Doulos Ltd. Church Hatch, 22 Marketing Place, Ringwood, Hampshire, BH24 
1AW, UK
Tel:  + 44 (0)1425 471223		Email: alan.fitch@doulos.com	
Fax:  +44 (0)1425 471573		http://www.doulos.com

------------------------------------------------------------------------

This message may contain personal views which are not the views of 
Doulos, unless specifically stated.

Article: 139329
Subject: Best way to export Xilinx EDK project in ISE and how to initialize
From: hassen.karray@gmail.com
Date: Thu, 26 Mar 2009 09:32:38 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

Question 1 : I made an EDK design based on Xilinx's microblaze
processor.
Now i want to use that design as a sub system in a Top VHDL design in
ISE.
I know it is possible to import the system.xps file and instancite it
within the ISE project.
I want to know about your ways and methodes to do that. (Importing XPS
file , system_stub .. ?)

Question 2 : Assuming i succeeded importing the design, I will then
use it as a component in a top module Vhdl file alongside other
components. Then i will be able to generate the bitstream file of the
whole design.
My question is: How can i initialize Brams to make them contain
the .elf software file in that bitstream file before downloading it in
the FPGA.

Best regards,
Hassen.



Article: 139330
Subject: Re: FPGAs in automotive apps
From: rickman <gnuarm@gmail.com>
Date: Thu, 26 Mar 2009 09:51:49 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 26, 9:24=A0am, whygee <why...@yg.yg> wrote:
> Hello,
>
> I think that KJ has some valid points, though
> they could be stated more clearly.
> I'm not in the automotive branch but I know that today,
> automakers don't want stock, they work with very short
> supplies to reduce costs and risks.
>
> Hence auto parts makers don't work with a visibility
> of more than months, sometimes weeks,
> and volumes below the 10K units range.
> Too low and short for ASICs,
> a fundry needs 6 to 12 weeks at the very least.
>
> Furthermore, what if a critical element has a bug
> that causes accidents ? Does the part maker remakes
> masks, then makes new PCBs for the chip ? No.
> Recall all the driving units in auto repair shops,
> plug a probe on the FPGA and that's all.
> It does not make a big difference, which in fact makes
> a big difference for the parts maker that
> won't have to finance and build new PCB modules wich contains
> more than a single $2 chip on it.

The issue of supply applies to *any* component in an auto.  An ASIC is
no different than a brake caliper or a piston ring.  The supply does
not need to be predicted any better than other parts.

As to recalls, bugs in an automotive product are just too expensive to
allow if at all possible.  The real cost in a recall is the recall
itself.  When was the last time you put your car in the shop and the
labor costs were not the biggest part of the bill?  Even if they
replace a wiperblade at the dealer it costs you an arm and a leg.

Recalls are very infrequent by necessity.  That is why auto makers
spend a lot of time and money on getting it right the first time.
ASICs fit that model very well since *no one* wants to have to pay to
redesign one.  So a lot of effort has been put into making sure that
the ASIC design process allows for getting them right the first time.
That is one of the big advantages of prototyping with FPGAs.  You have
all the flexibility of the FPGA when the design might change and
later, once the initial production is underway and the design is
proven in the field, the ASIC can be designed in giving the lowest
product cost as mandated by high volume manufacturing.


> rickman wrote:
> > My "opinions" are factual as far as I can tell. =A0Perhaps we have not
> > explored all the details, but the economics are clear.
>
> but incomplete, you only accounted for 1 part of a larger assembly.
> and in cars, ASICs are not socketed...
>
> > Unless the cost is nearly zero, as is the case of having your FPGA
> > vendor provide you with an ASIC based on the FPGA bit file. =A0If you
> > buy a minimum quantity, they will not charge NRE at all. =A0Your only
> > expense is in discussing this with your management and getting a
> > signoff. =A0So if you are talking about a product in *high volume*
> > production, the trade off is trivial.
>
> however, high volume is not the norm anymore, as this means huge stocks
> and investments that nobody wants to do anymore. And with the current
> crisis, no accountant will hear your argument : they will prefer to pay
> a bit more per unit, just to not have to buy huge quantities of stuff tha=
t they
> have no assurance to resell to the automaker...
> And by the time you have sold the last ASICs of your stock,
> your product is already in rev.2 or 3.

Why does high volume require huge stocks and investments?  You don't
have to buy a million ASIC devices when you place your first order.
They are supplied JIT (just in time) as is everything else in the auto
industry these days.  Your logic here is very out of date with
technology and practice.


> IMHO the problem is not FPGA but ASICs :
> too slow to build, too expensive and too large volumes
> for today's markets, despite technical advantages.

You have ignored most of what I have written.  The development time
issue is dealt with by using FPGAs in development and initial
production.  To say they are "expensive" is ignoring the facts.  ASICs
have high NRE and low recurring costs.  In high volume manufacturing
recurring costs dominate by a factor of millions.  The technical
advantages of ASICs are minimal with today's semiconductor
technology.  There are not many problems that can't be solved by
FPGAs.  The only issue is the 2 to 10 times higher unit cost.


> > The FPGA companies have explored pretty
> > much every single one and have shouted them from the rooftops.
>
> And I recently heard Actel claiming success (?) in the automotive branch.
> I leave the marketspeech analysis as an exercise,
> BUT the fact is that they have (some) happy clients.

I have no doubt that there are FPGAs in automobiles.  I have stated
several times that FPGAs will be used anytime that reconfigurability
is important.  They will also be used any time the volumes are not so
high.  My point is that because they are not used where the volumes
*are* high, the automotive market is not a primary market for FPGA
makers.  The end result is that FPGA technology is not steered in the
direction that optimizes these parts for automotive use.  That is the
initial point that started this debate of auto use.


> > =A0But few auto products ever need upgraded hardware.
>
> Now think about the Pentium FDIV bug in your brake or injection system.
> Think accidents, lawsuits, huge costs for recalling all the cars
> and changing the critical element.
> Given the complexity and stakes, I believe that the decision
> to use FPGA in certain places is not stupid for some bosses.
> If the dev team ever tell the CEO that there is this option
> (which does not necessarily happens).

***EXACTLY***!!!  If they give these issues the attention they deserve
they will make sure the bugs are not there in the first place.  The
cost of fixing a bug like this is virtually nothing compared to the
potential cost from liability.  Using FPGAs does nothing to prevent
the accidents or injury, they do nothing to prevent or mitigate the
lawsuits.  Using FPGA does little to reduce the expense of a recall.


> > It just does not make sense to leave money laying on the
> > table. =A0No CEO would do that.
>
> The CEO may have constraints that you don't know, like time,
> availability, projected and actual shipped quantities, whatever...
> It depends on a many more parameters than only the unit price
> in huge quantities.

I remember discussing flying saucers when I was in school.  I would
present the facts at hand about how the claimed saucers do things that
are impossible by the laws of physics as we know them.  One of the
responses would be that maybe we don't know about the part of the
universe they were from or that they discovered things we don't know.
Sure, anything is possible, in theory.  But unless some facts are
presented to show that saucers were real, why should we assume that
everything we know is wrong and little green men are watching us?

If the CEO has facts at hand that mitigate the cost reduction possible
with ASICs, then they will make the decision to stick with FPGAs.  I
have already stated several times that one clear reason to use FPGAs
in volume is when the reconfigurability is important to the product.
The quantities shipped are the main qualification stated, so I don't
understand what you mean by that.  Otherwise, I don't know of any
examples of FPGAs being used in large volumes in autos.  So I don't
see any reason why the FPGA companies will be targeting product
development toward auto usage... and I don't believe in flying saucers
either.

If Martin won't tell us why his company wants to use FPGAs instead of
ASICs, then maybe he can at least come back whey they have shipped
250,000 units of a single product and tell us if they are still
sticking with FPGAs instead of an ASIC.

Rick

Article: 139331
Subject: Re: FPGAs in automotive apps
From: rickman <gnuarm@gmail.com>
Date: Thu, 26 Mar 2009 09:57:08 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 26, 5:07=A0am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
> rickman <gnu...@gmail.com> writes:
>
> > You miss the point. =A0Flash micros are in production products because
> > there is very little price differential with metal layer ROM devices.
> > Otherwise the ROM parts would "abound" in high volume products.
>
> Yes. =A0That wasn't always the case. =A0Things develop.

I don't know what you mean by that.  Of course they develop.  That is
why the ROM parts have little price advantage and are not used nearly
as often not... flash developed and dropped tremendously in price.  If
FPGAs find a way to drop in price to a point where there is little
cost advantage of using an ASIC, then even in high volume applications
the FPGAs will be used.  But so far they are still 10x larger and
several times more in price than ASICs.


> >> By the time these driver assistance features are on the *really*
> >> high-volume vehicles FPGAs will be even cheaper than they are now.
>
> > Yes, and the bean counters at every company will be beating you
> > mercilessly to cut every penny from the cost. =A0When you are facing th=
e
> > loss of a $10M contract because you need to cut the cost by another
> > $1, the decision will be made to go with an ASIC. =A0How else are you
> > going to cut the cost of this product otherwise?
>
> > You can say you "know what you are doing", but the economics are what
> > they are. =A0If your company sells a high volume product using an FPGA
> > instead of an ASIC, when you don't need reconfigurability, you are
> > leaving money on the table. =A0Not many CEOs like that idea.
>
> > Is there some rational for not designing an ASIC for a high volume
> > product that is out of development and meets all specs? =A0Don't tell m=
e
> > you are doing it, tell me *why* you are doing it. =A0Companies make
> > mistakes all the time. =A0I would like to know the reason for this
> > decision or if it is just a temporary choice and will change as the
> > volumes increase.
>
> I think KJ wrote quite nicely why I'm not going to explain all that in
> a public forum - sorry! =A0(And I don't do the lottery, so that's not
> likely to change :)

I understand.  But until I see a product shipping a million units with
FPGAs that is not using their reconfigurability as an important
feature, I won't believe that any company would ignore a few million
dollars that could be had by simply asking the FPGA vendor for their
equivalent ASIC device.

Enough said?

Rick

Article: 139332
Subject: Re: FPGA users, Please take a few seconds to report SPAM
From: rickman <gnuarm@gmail.com>
Date: Thu, 26 Mar 2009 10:05:00 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 26, 10:08=A0am, VAX9...@gmail.com wrote:
> On Mar 20, 7:14=A0pm, James Harris <james.harri...@googlemail.com>
> wrote:
>
> > I have been reportingspamon other groups and, after a long time, the
> > senders Google accounts were removed. I think it took about four to
> > eight weeks. I send this to reassure that they do seem to take notice
> > eventually but patience is required.
>
> As of today, it seems Google is taking action. The board is much
> cleaner now.

They seem to have made is easier to report spam as well.  A link is
provided under "More Options" and the default checkbox is SPAM.  All I
have to do is to type "spam" in the description and it is accepted.  I
seem to recall that it used to be a much bigger PITA to report spam.

Rick

Article: 139333
Subject: Re: added jitter on FPGAs
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Thu, 26 Mar 2009 10:53:43 -0700
Links: << >>  << T >>  << A >>
On Wed, 26 Nov 2008 10:05:06 -0800 (PST), palvarez
<pabloalvarezsanchez@gmail.com> wrote:

>Hi,
>
>For several reasons a need very low jitter on some of my outputs. I
>was thinking of using LVDS for my I/Os and of course I do not consider
>using a clock manager. Do you have an idea of the order of magnitude
>of jitter one can get? What fpga would you recomend for a low cost
>small design?
>
>Cheers
>
>Pablo


Here's a signal that has made three independent non-trivial in/out
passes through a Spartan3, plus passed through six external SSI CMOS
chips. Total jitter of that whole chain is below 20 ps RMS.

ftp://jjlarkin.lmi.net/Jitter3.jpg


We were fairly impressed. Spartans are like having a few thousand 10KH
ECL gates on a $20 chip.

John



Article: 139334
Subject: Accessing data from flash memory
From: mopra <mohitprakas@gmail.com>
Date: Thu, 26 Mar 2009 11:56:16 -0700 (PDT)
Links: << >>  << T >>  << A >>
Can I read from a file as well as write when using sysace functions
when accessing data from flash memory.


Regards
Mohit Prakash

Article: 139335
Subject: Re: added jitter on FPGAs
From: "Andrew Holme" <ah@nospam.co.uk>
Date: Thu, 26 Mar 2009 19:34:22 -0000
Links: << >>  << T >>  << A >>

"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message 
news:nhfns4lrd245pvu2lt4pnn03lio466j5ti@4ax.com...
> On Wed, 26 Nov 2008 10:05:06 -0800 (PST), palvarez
> <pabloalvarezsanchez@gmail.com> wrote:
>
>>Hi,
>>
>>For several reasons a need very low jitter on some of my outputs. I
>>was thinking of using LVDS for my I/Os and of course I do not consider
>>using a clock manager. Do you have an idea of the order of magnitude
>>of jitter one can get? What fpga would you recomend for a low cost
>>small design?
>>
>>Cheers
>>
>>Pablo
>
>
> Here's a signal that has made three independent non-trivial in/out
> passes through a Spartan3, plus passed through six external SSI CMOS
> chips. Total jitter of that whole chain is below 20 ps RMS.
>
> ftp://jjlarkin.lmi.net/Jitter3.jpg
>
>
> We were fairly impressed. Spartans are like having a few thousand 10KH
> ECL gates on a $20 chip.
>
> John
>

I've just built a fractional-N synthesizer using a Spartan 3.  The reference 
frequency comes from an LVDS-output crystal oscillator.  The VCO frequency 
is fed into the opposite side of the FPGA using an LVDS-output comparator 
and the (AD9901 style) PFD output from the FPGA to the loop filter is also 
LVDS on a third physical side.

Inside the FPGA, the VCO divider and reference divider are on local clocks 
confined to small regions around the pads where they enter.  BUFGCE 
primitives are used to gate the clocks so I only send edges over the global 
clock network when a divider resets.  The AD9901 PFD ensures that the VCO 
and reference divider outputs are 180 degrees out of phase.

Some years ago, I built a cruder fractional-N synth using a 5V Altera PLCC84 
CPLD.  It worked quite well, but there was some interation between the VCO 
and reference frequencies which caused integer-N boundary spurs.  I see no 
trace of these spurs on my new Spartan 3 design, and the phase noise is much 
lower.  I'm seeing around -95 dBc/Hz at 100 Hz offsets at the moment; and I 
haven't finished tweaking things yet.


They say don't attempt analogue functions in FPGAs; but it seems to work 
remarkably well in the Spartan 3, which is fully static when I'm not 
clocking it.




Article: 139336
Subject: Re: added jitter on FPGAs
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Thu, 26 Mar 2009 13:39:47 -0700
Links: << >>  << T >>  << A >>
On Thu, 26 Mar 2009 19:34:22 -0000, "Andrew Holme" <ah@nospam.co.uk>
wrote:

>
>"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message 
>news:nhfns4lrd245pvu2lt4pnn03lio466j5ti@4ax.com...
>> On Wed, 26 Nov 2008 10:05:06 -0800 (PST), palvarez
>> <pabloalvarezsanchez@gmail.com> wrote:
>>
>>>Hi,
>>>
>>>For several reasons a need very low jitter on some of my outputs. I
>>>was thinking of using LVDS for my I/Os and of course I do not consider
>>>using a clock manager. Do you have an idea of the order of magnitude
>>>of jitter one can get? What fpga would you recomend for a low cost
>>>small design?
>>>
>>>Cheers
>>>
>>>Pablo
>>
>>
>> Here's a signal that has made three independent non-trivial in/out
>> passes through a Spartan3, plus passed through six external SSI CMOS
>> chips. Total jitter of that whole chain is below 20 ps RMS.
>>
>> ftp://jjlarkin.lmi.net/Jitter3.jpg
>>
>>
>> We were fairly impressed. Spartans are like having a few thousand 10KH
>> ECL gates on a $20 chip.
>>
>> John
>>
>
>I've just built a fractional-N synthesizer using a Spartan 3.  The reference 
>frequency comes from an LVDS-output crystal oscillator.  The VCO frequency 
>is fed into the opposite side of the FPGA using an LVDS-output comparator 
>and the (AD9901 style) PFD output from the FPGA to the loop filter is also 
>LVDS on a third physical side.
>
>Inside the FPGA, the VCO divider and reference divider are on local clocks 
>confined to small regions around the pads where they enter.  BUFGCE 
>primitives are used to gate the clocks so I only send edges over the global 
>clock network when a divider resets.  The AD9901 PFD ensures that the VCO 
>and reference divider outputs are 180 degrees out of phase.
>
>Some years ago, I built a cruder fractional-N synth using a 5V Altera PLCC84 
>CPLD.  It worked quite well, but there was some interation between the VCO 
>and reference frequencies which caused integer-N boundary spurs.  I see no 
>trace of these spurs on my new Spartan 3 design, and the phase noise is much 
>lower.  I'm seeing around -95 dBc/Hz at 100 Hz offsets at the moment; and I 
>haven't finished tweaking things yet.
>
>
>They say don't attempt analogue functions in FPGAs; but it seems to work 
>remarkably well in the Spartan 3, which is fully static when I'm not 
>clocking it.
>
>

The Spartan LVDS inputs are pretty good r-r comparators. And you can
make lots of good, cheap delta-sigma dacs from an FPGA.

You can do cool analog things with FPGAs. You can also get into a heap
of trouble.

John


Article: 139337
Subject: Re: Dynamic reconfiguration in Spartan 3
From: austin <austin@xilinx.com>
Date: Thu, 26 Mar 2009 14:53:39 -0700 (PDT)
Links: << >>  << T >>  << A >>
Moazzam,

Spartan 3 does not support dynamic reconfiguration.

Austin

Article: 139338
Subject: Re: added jitter on FPGAs
From: nico@puntnl.niks (Nico Coesel)
Date: Thu, 26 Mar 2009 23:02:35 GMT
Links: << >>  << T >>  << A >>
John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

>On Wed, 26 Nov 2008 10:05:06 -0800 (PST), palvarez
><pabloalvarezsanchez@gmail.com> wrote:
>
>>Hi,
>>
>>For several reasons a need very low jitter on some of my outputs. I
>>was thinking of using LVDS for my I/Os and of course I do not consider
>>using a clock manager. Do you have an idea of the order of magnitude
>>of jitter one can get? What fpga would you recomend for a low cost
>>small design?
>>
>>Cheers
>>
>>Pablo
>
>
>Here's a signal that has made three independent non-trivial in/out
>passes through a Spartan3, plus passed through six external SSI CMOS
>chips. Total jitter of that whole chain is below 20 ps RMS.
>
>ftp://jjlarkin.lmi.net/Jitter3.jpg

I presume this is without routing the clock through the DCM :-)

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------

Article: 139339
Subject: Re: added jitter on FPGAs
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Thu, 26 Mar 2009 16:10:04 -0700
Links: << >>  << T >>  << A >>
On Thu, 26 Mar 2009 23:02:35 GMT, nico@puntnl.niks (Nico Coesel)
wrote:

>John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:
>
>>On Wed, 26 Nov 2008 10:05:06 -0800 (PST), palvarez
>><pabloalvarezsanchez@gmail.com> wrote:
>>
>>>Hi,
>>>
>>>For several reasons a need very low jitter on some of my outputs. I
>>>was thinking of using LVDS for my I/Os and of course I do not consider
>>>using a clock manager. Do you have an idea of the order of magnitude
>>>of jitter one can get? What fpga would you recomend for a low cost
>>>small design?
>>>
>>>Cheers
>>>
>>>Pablo
>>
>>
>>Here's a signal that has made three independent non-trivial in/out
>>passes through a Spartan3, plus passed through six external SSI CMOS
>>chips. Total jitter of that whole chain is below 20 ps RMS.
>>
>>ftp://jjlarkin.lmi.net/Jitter3.jpg
>
>I presume this is without routing the clock through the DCM :-)

Yes! One of the three FPGA inputs is in fact a global clock, but it's
not multiplied or anything.

In another mode, we do double a 40 MHz clock to 80 in a DCM. That adds
about 80 ps p-p jitter, because it wiggles alternate 80 MHz clock
edges.

John


Article: 139340
Subject: Re: Looking for a low-cost development kit
From: LittleAlex <alex.louie@email.com>
Date: Thu, 26 Mar 2009 16:45:59 -0700 (PDT)
Links: << >>  << T >>  << A >>

<http://www.latticesemi.com/products/developmenthardware/
developmentkits/machxominidevelopmentkit.cfm>

On-line price is $59

On Mar 25, 12:35 pm, News123 <news...@free.fr> wrote:
> Lattice seems to have several FPGA development kits.
>
> Do you have by any chance the reference number of your kit or a URL?
>
> LittleAlex wrote:
> > I just got an FPGA development kit from Lattice - 2200 CLB's, USB
> > (FX2) Interface, a software starter kit, and an 8-bit embedded
> > processor.
>
> > $75 including tax & Shipping.
>
> > Software license expires every 6 months; I'm guessing that they will
> > renew it.  Software is reminiscent of Xilinx back in the ISE-4.2 days
> > (clumsy, but functional).  The embedded processor (Mico8) looks -very-
> > interesting: if I'm seeing things correctly, they chose 'wishbone' for
> > their on-chip bus.
>
> > AL


Article: 139341
Subject: Re: virtex-5 lvds termination issue?
From: Brian Davis <brimdavis@aol.com>
Date: Thu, 26 Mar 2009 19:26:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
>
> I looked at the ADC/FPGA interface with a DSO and there are large
> over/undershoots which seem to be caused by significant reflections.
>

 Some past posts that might be useful, regarding the use of
other high speed LVDS A/D's lacking driver back termination :

 http://groups.google.com/group/comp.arch.fpga/msg/85db6dc0bca5c0da
 http://groups.google.com/group/comp.arch.fpga/msg/95809af82ccbb550
 http://groups.google.com/group/comp.arch.fpga/msg/5a8720eec942612e

 The pdf files referenced in the above posts have now moved here:

 http://fpgastuff.googlepages.com/oldaolfiles

 ( Last fall, AOL silently axed the ftp space where I'd been
stashing examples for the past decade )

Brian

Article: 139342
Subject: Re: FPGAs in automotive apps
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Fri, 27 Mar 2009 09:54:55 +0000
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> writes:
<snip>
>
> Enough said?
>
> Rick
I think so :)

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

Article: 139343
Subject: Re: Best way to export Xilinx EDK project in ISE and how to initialize Brams ?
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Fri, 27 Mar 2009 11:01:40 +0000
Links: << >>  << T >>  << A >>
hassen.karray@gmail.com writes:

> Hi,
>
> Question 1 : I made an EDK design based on Xilinx's microblaze
> processor.  Now i want to use that design as a sub system in a Top
> VHDL design in ISE.  I know it is possible to import the system.xps
> file and instancite it within the ISE project.  I want to know about
> your ways and methodes to do that. (Importing XPS file , system_stub
> .. ?)

I don't use ISE, I use a command-line flow.  I've instanced system.vhd
in my top level VHDL file, synthesised the whole thing to an EDF file,
then my implementation script brings in the NGCs from XPS and the runs
a normal place and route flow.

>
> Question 2 : Assuming i succeeded importing the design, I will then
> use it as a component in a top module Vhdl file alongside other
> components. Then i will be able to generate the bitstream file of the
> whole design.  My question is: How can i initialize Brams to make them
> contain the .elf software file in that bitstream file before
> downloading it in the FPGA.

I added :
  -bmm <path_to_bmmfile> to my NGDBUILD command line
  -bd <path_to_elf> to my bitgen command line.

HTH,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

Article: 139344
Subject: Re: Dynamic reconfiguration in Spartan 3
From: Dirk Koch <dirk.koch@cs.fau.de>
Date: Fri, 27 Mar 2009 12:55:52 +0100
Links: << >>  << T >>  << A >>
samece wrote:
> hi all,
> Is dynamic reconfiguration of microblaze implemented in a Spartan 3 fpga
> kit possible? If so may anyone help me in that area.
> 
> 
Samece,
Yes partial self reconfiguration is possible on Spartan-3!
Spartan-3 does not provide an ICAP, but you can simply loop
back some I/O pins to an external reconfiguration port.
I am using an S3 Board from Digilent where you can simply
plug some wires in the B1 connector for looping back a PIO
port to the select map interface (no soldering required).
By the way, Spartan-3AN, Spartan-3A posses an ICAP port.

But:
A S3 configuration is not simply overwritten, but (CLB-)
columnwise deleted (by executing a snowplow command)
and then written in a frame by frame manner.
Consequently, routing that is carried out in a currently
reconfigured CLB-column is completely cut off.
This includes also the top/bottom I/O!
This is often ambiguously called 'glitch', but this
interruption can take thousands of clock cycles.
We have a paper on these issues:
A Communication Architecture for Complex Runtime Reconfigurable
Systems and its Implementation on Spartan-3 FPGAs.
Can be found on our project website:

www.recobus.de

There are also some restrictions using Xilinx tools
to design runtime reconfigurable systems. This holds true
especially for Spartan-3 Devices.
Our tool ReCoBus-Builder (also available on the website)
is easy to use and provides capabilities not available
in the 'normal' PR flow.
Drop us a mail, if your Spartan 3 (-E/A/AN) is not in the
device list).

Regards

Dirk

Article: 139345
Subject: Re: Dynamic reconfiguration in Spartan 3
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Fri, 27 Mar 2009 04:57:48 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 27, 1:55=A0pm, Dirk Koch <dirk.k...@cs.fau.de> wrote:
> samece wrote:
> > hi all,
> > Is dynamic reconfiguration of microblaze implemented in a Spartan 3 fpg=
a
> > kit possible? If so may anyone help me in that area.
>
> Samece,
> Yes partial self reconfiguration is possible on Spartan-3!
> Spartan-3 does not provide an ICAP, but you can simply loop
> back some I/O pins to an external reconfiguration port.
> I am using an S3 Board from Digilent where you can simply
> plug some wires in the B1 connector for looping back a PIO
> port to the select map interface (no soldering required).
> By the way, Spartan-3AN, Spartan-3A posses an ICAP port.
>
> But:
> A S3 configuration is not simply overwritten, but (CLB-)
> columnwise deleted (by executing a snowplow command)
> and then written in a frame by frame manner.
> Consequently, routing that is carried out in a currently
> reconfigured CLB-column is completely cut off.
> This includes also the top/bottom I/O!
> This is often ambiguously called 'glitch', but this
> interruption can take thousands of clock cycles.
> We have a paper on these issues:
> =93A Communication Architecture for Complex Runtime Reconfigurable
> Systems and its Implementation on Spartan-3 FPGAs.=94
> Can be found on our project website:
>
> www.recobus.de
>
> There are also some restrictions using Xilinx tools
> to design runtime reconfigurable systems. This holds true
> especially for Spartan-3 Devices.
> Our tool ReCoBus-Builder (also available on the website)
> is easy to use and provides capabilities not available
> in the 'normal' PR flow.
> Drop us a mail, if your Spartan 3 (-E/A/AN) is not in the
> device list).
>
> Regards
>
> Dirk

Dirk

Recobus website says only Spartan-3 is supported :(

I assumed that this means that Spartan-3A is not supported what made
me very sad

So whats the real story? Spartan 3A are supported or not?

Antti






Article: 139346
Subject: Re: Best way to export Xilinx EDK project in ISE and how to
From: gabor <gabor@alacron.com>
Date: Fri, 27 Mar 2009 05:58:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 26, 12:32=A0pm, hassen.kar...@gmail.com wrote:
> Hi,
>
> Question 1 : I made an EDK design based on Xilinx's microblaze
> processor.
> Now i want to use that design as a sub system in a Top VHDL design in
> ISE.
> I know it is possible to import the system.xps file and instancite it
> within the ISE project.
> I want to know about your ways and methodes to do that. (Importing XPS
> file , system_stub .. ?)
>

If you use the ISE GUI, just add the .xmp file to your
project.  It should be handled correctly.

> Question 2 : Assuming i succeeded importing the design, I will then
> use it as a component in a top module Vhdl file alongside other
> components. Then i will be able to generate the bitstream file of the
> whole design.

Once you have added the EDK project to ISE, you will be able to
click it in the sources view and find its processes in the
window below that.  Processes include "View HDL Instantiation
Template", which is an easy way to slip the design into your
top level source code in ISE.

> My question is: How can i initialize Brams to make them contain
> the .elf software file in that bitstream file before downloading it in
> the FPGA.
>

After you build the ISE project, you will find a process at the
end of the processes window titled "Update Bitstream with
Processor Data".  This process does what you want.  It also
runs very quickly, taking much less time than "Generate
Program File".

> Best regards,
> Hassen.


Article: 139347
Subject: PLL in Actel Igloo part
From: jfh <jfhasson@club-internet.fr>
Date: Fri, 27 Mar 2009 06:03:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

We are working on a project involving the Igloo part from Actel. We
have a 20 MHz clock which may present a stable logic state (either '1'
or '0') for up to 150 ns. We don't expect this event to occur very
often (not more than once per second). We were thinking of using the
PLL of the Igloo part to filter out this unnwanted state of the clock.
The characteristics of the PLL are up to 45kHz loop bandwidth (seen in
the datasheet). We did a test on an Igloo dev kit (icicle) and the
Igloo PLL looses lock. The unwanted event is repeated every 3 ms and
lasts 150 ns.The loss of lock is very fast and just before the lock
comes back the output clock from the PLL disappears for a few hundred
ns. How come regarding the characteristics of the PLL ? Any ideas ?

Best regards,

JF

Article: 139348
Subject: Re: PLL in Actel Igloo part
From: gabor <gabor@alacron.com>
Date: Fri, 27 Mar 2009 06:32:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 27, 9:03=A0am, jfh <jfhas...@club-internet.fr> wrote:
> Hi,
>
> We are working on a project involving the Igloo part from Actel. We
> have a 20 MHz clock which may present a stable logic state (either '1'
> or '0') for up to 150 ns. We don't expect this event to occur very
> often (not more than once per second). We were thinking of using the
> PLL of the Igloo part to filter out this unnwanted state of the clock.
> The characteristics of the PLL are up to 45kHz loop bandwidth (seen in
> the datasheet). We did a test on an Igloo dev kit (icicle) and the
> Igloo PLL looses lock. The unwanted event is repeated every 3 ms and
> lasts 150 ns.The loss of lock is very fast and just before the lock
> comes back the output clock from the PLL disappears for a few hundred
> ns. How come regarding the characteristics of the PLL ? Any ideas ?
>
> Best regards,
>
> JF

A standard PLL attempts to lock continuously to the input signal.
So even if the clock comes back at the same phase after the event,
the PLL will have slewed its VCO significantly during the event,
causing the loss of lock.  You can try to compensate for this by
reducing the filter bandwidth.  However if you know when the clock
losses will occur the ideal approach is to use a PLL with hold
capability, like those used in the AD988x Analog Flat Panel
interface chips from Analog Devices.  Those PLL's can "coast"
during vertical sync, essentially shutting off the feedback loop
while the horizontal sync is interrupted.

I'm not familiar with the Actel parts, but Lattice FPGA's have
external capacitor pins for their PLL's to allow you to reduce
the filter bandwidth.

Regards,
Gabor

Article: 139349
Subject: best soft core(s) that have C compiler support
From: Antti <Antti.Lukats@googlemail.com>
Date: Fri, 27 Mar 2009 07:13:14 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi

i know has been discussed before ;)

if we leave out the vendor supplied ones (including open source like
mico32)
and the large ones, then my current list:

Core   Datapath width   Spartan-3 slices for small SoC (approx, ISE
10.1 results)
ZPU    32                     1000
C16    16                     1000
i8080  8                       1000
L8080 8                       450
L8080 8                       150 + 1 BRAM for microcode

ZPU is stack based so most weird, but it has GCC support
C16 has its own assembler/compiler/simulator supplied with source code
i8080/L8080 are intel 8080 - I assume there is some  C compiler
available
L8080 (lightweight 8080) not sure if it is correct enogh to run c
compiler code

I wonder if there are better candidates for each bit-width category
microblaze clone could be considered for 32, but i would rather leave
such clones out from the table

Antti











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