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 134725

Article: 134725
Subject: Timing analyser
From: knight <krsheshu@gmail.com>
Date: Wed, 27 Aug 2008 20:56:43 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi

Im using timing analyser.
This is a part of my timing report

    Data Path: reset to U1/count_9
    Delay type         Delay(ns)  Logical Resource(s)
    ----------------------------  -------------------
    Tiopi                 1.300            reset
                                              reset_IBUF
    net (fanout=16)  0.444           reset_IBUF
    Tilo                   0.759           U1/count_or00001
  * net (fanout=11)  0.674           U1/count_or0000
    Tsrck                 0.910          U1/count_9
    ----------------------------  ---------------------------
    Total                 4.087ns (2.969ns logic, 1.118ns route)
                                  (72.6% logic, 27.4% route)


Actuallty U1/count_or00001 is a [FG] which sources more than 20
FlipFlops reset ( which i can see in floorplanner).
And the driving net is  U1/count_or0000.( this should source more than
20 FFs)
Then why is the fanout given as 11 ..? (Please refer to * in the
report)
Shouldnt it be greater than 20..?

Article: 134726
Subject: Mass storage device on ML403 board
From: "G. Carvajal" <gcarvajalb@gmail.com>
Date: Thu, 28 Aug 2008 00:13:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi there,

I need to implement a mass storage device on this board. My first
approach was using the xilfatfs library for saving the data on a CF
memory, but I'm facing a lot of problems with that. The system turns
pretty unstable, and after some weeks trying to fixed it, we can't
figured out where is the problem. The only guess is that there is a
bad memory management from the xilfatfs library functions.

Currently I'm running the test in stand alone configuration. Some
sugestions said that maybe we can try using Linux instead. However, I
was making some research and I couldn't find drivers for using the CF
card or the USB port with a mass storage device. Have anybody tried to
do this before? Do you know if there are drivers that supports these
characteristics?

I have to said that I'm not totally familiar with Linux OS
descriptions and it will be my first attempt to run it in the FPGA.
I'm trying to follow some example receipts which didn't include
support for these characteristics, so maybe I'm missing something and
I'm not looking for the right terms.

I know that it would be a lot of work to run Linux and configurate the
system again, so I would like to know if there is support for these
devices before start the adventure.

Thanks a lot.

Article: 134727
Subject: Re: Genode FPGA graphics project launched
From: nfeske <norman.feske@genode-labs.com>
Date: Thu, 28 Aug 2008 00:27:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi Jon,

> Looks interesting. Would the LGPL license be more appropriate though?
> For example, can you legally distribute a project based on the GPLed
> Genode that also uses MicroBlaze/NIOS, as doing so would presumably
> require you to provide the MicroBlaze source as well, which will
> obviously be a problem.

According to the License text, the terms about the modification and
distribution of GPL'ed source code apply only to derivative work,
which is work that takes GPL source code as a starting point. The
Microblaze is clearly not derived work because it does not depend in
any way on the components Genode FX provides.

Regards
Norman

Article: 134728
Subject: Re: Virtex 5 bitstream encryption
From: bamboutcha9999@hotmail.com
Date: Thu, 28 Aug 2008 00:43:14 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 27 ao=FBt, 18:29, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> bamboutcha9...@hotmail.com wrote:
> > Hello !
> > =A0I would like to know the frequency used by Xilinx (Virtex 5) to
> > decrypt bitstream before configuration .
> > =A0The decrypter is it slow with small area ? fast with big area ?
> > unfortunately it's not documented by xilinx .
>
> > Thank u for help
>
> It decrypts at the same rate as the configuration clock. =A0This could be
> anywhere from KHz to the maximum of 100 MHz as specified in the data shee=
t.
>
> Ed McGettigan
> --
> Xilinx Inc.


Ed ,
thank for you answer .
The rate of config clk is fixed by the user ( from 2Mhz to 60Mhz ) so
i did not understand by "anywhere from KHz to the maximum of 100
MHz" , moreover with my
encrypted bitstream (Eprom =3D>  FPGA) i couldn't run over 42 Mhz .
why ?
What i want to know is the throughput of the decrypter (AES 256 CBC) ,
how many cycles takes this architecture used by Xilinx ? is it Safe
at  100% against attacks ( timing , fault attack , side channel
attack ....) ?
thank u

Article: 134729
Subject: Re: Genode FPGA graphics project launched
From: Jon Beniston <jon@beniston.com>
Date: Thu, 28 Aug 2008 01:29:00 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 28 Aug, 08:27, nfeske <norman.fe...@genode-labs.com> wrote:
> Hi Jon,
>
> > Looks interesting. Would the LGPL license be more appropriate though?
> > For example, can you legally distribute a project based on the GPLed
> > Genode that also uses MicroBlaze/NIOS, as doing so would presumably
> > require you to provide the MicroBlaze source as well, which will
> > obviously be a problem.
>
> According to the License text, the terms about the modification and
> distribution of GPL'ed source code apply only to derivative work,
> which is work that takes GPL source code as a starting point. The
> Microblaze is clearly not derived work because it does not depend in
> any way on the components Genode FX provides.

Using GPLed code means that all code in a project must be open source.
No proprietary stuff. Anything that uses Genode is a derived work. If
you want to allow use with proprietary code, then the LGPL should be
used.

See here: http://www.gnu.org/philosophy/why-not-lgpl.html

"The GNU Project has two principal licenses to use for libraries. One
is the GNU Lesser GPL; the other is the ordinary GNU GPL. The choice
of license makes a big difference: using the Lesser GPL permits use of
the library in proprietary programs; using the ordinary GPL for a
library makes it available only for free programs."

Jon

Article: 134730
Subject: Re: Genode FPGA graphics project launched
From: Antti <Antti.Lukats@googlemail.com>
Date: Thu, 28 Aug 2008 02:18:16 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 28 aug, 11:29, Jon Beniston <j...@beniston.com> wrote:
> On 28 Aug, 08:27, nfeske <norman.fe...@genode-labs.com> wrote:
>
> > Hi Jon,
>
> > > Looks interesting. Would the LGPL license be more appropriate though?
> > > For example, can you legally distribute a project based on the GPLed
> > > Genode that also uses MicroBlaze/NIOS, as doing so would presumably
> > > require you to provide the MicroBlaze source as well, which will
> > > obviously be a problem.
>
> > According to the License text, the terms about the modification and
> > distribution of GPL'ed source code apply only to derivative work,
> > which is work that takes GPL source code as a starting point. The
> > Microblaze is clearly not derived work because it does not depend in
> > any way on the components Genode FX provides.
>
> Using GPLed code means that all code in a project must be open source.
> No proprietary stuff. Anything that uses Genode is a derived work. If
> you want to allow use with proprietary code, then the LGPL should be
> used.
>
> See here:http://www.gnu.org/philosophy/why-not-lgpl.html
>
> "The GNU Project has two principal licenses to use for libraries. One
> is the GNU Lesser GPL; the other is the ordinary GNU GPL. The choice
> of license makes a big difference: using the Lesser GPL permits use of
> the library in proprietary programs; using the ordinary GPL for a
> library makes it available only for free programs."
>
> Jon

if you claim that then you can equally force Xilinx to release source
code of the microblaze
because the mb gcc is GPL licensed and not LPGL licensed

not always ALL project sources are needed to be made public if GPL
based part are
used in the project

depend how you define project and library
i can say its ALL one projects and microblaze is one VHDL library what
is linked to the
stuff compiled with GPL licensed tools, so microblaze also needs to be
GPL, etc..

i think the Xilinx lawer disagree with that

but in generic the GPLxxx stuff is not really applicable today for
FPGA ip cores and related stuff


Antti




Article: 134731
Subject: Re: Timing analyser
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 28 Aug 2008 10:18:49 +0100
Links: << >>  << T >>  << A >>
"knight" <krsheshu@gmail.com> wrote in message 
news:01250168-8d89-41c3-8c31-7fced56fcc62@m36g2000hse.googlegroups.com...
> Hi
>
>
>
> Actuallty U1/count_or00001 is a [FG] which sources more than 20
> FlipFlops reset ( which i can see in floorplanner).
> And the driving net is  U1/count_or0000.( this should source more than
> 20 FFs)
> Then why is the fanout given as 11 ..? (Please refer to * in the
> report)
> Shouldnt it be greater than 20..?

Sir Knight,
Have a look at the net in FPGA editor. I guess that two FFs in a slice get 
fed from a single pin.
HTH., Syms. 



Article: 134732
Subject: Re: Saving PAR Constraints
From: lux.junip@gmail.com
Date: Thu, 28 Aug 2008 02:19:09 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 27, 4:49=A0pm, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
> On Tue, 26 Aug 2008 23:39:53 -0700 (PDT), knight <krshe...@gmail.com>
> wrote:
>
> >I wanted to set some constraints in Floorplanner.
> >Every time i change a constraint in floorplanner, for example placing
> >a LUT,
> >and run PAR the whole placements of other blocks gets changed.
>
> >Is it possible to save the constraints generated after PAR..?
> >i want to first make other blocks static and place my block at
> >different locations and evaluate timing..
>
> I think you want to select "re-entrant flow" in the PAR properties menu
> (there will be a command line option for this if you are not using
> Project Navigator)
> Read how to use re-entrant flow in the PAR manual.
>
> - Brian

Hi,
You can open the Place and Route design in the FloorPlanner.
Go to Floorplan Menu -> Replace All with placement . This will copy
the currently placed design into the Editable Floorplanner.
Now you can do the required changed in the LUT location in the
edittable window.  Save this to the UCF file and use this as the UCF
file

Lux

Article: 134733
Subject: Re: Genode FPGA graphics project launched
From: nfeske <norman.feske@genode-labs.com>
Date: Thu, 28 Aug 2008 02:25:09 -0700 (PDT)
Links: << >>  << T >>  << A >>
> Using GPLed code means that all code in a project must be open source.
> No proprietary stuff. Anything that uses Genode is a derived work. If
> you want to allow use with proprietary code, then the LGPL should be
> used.
>
> See here:http://www.gnu.org/philosophy/why-not-lgpl.html

That discussion is going on for ages, for example about binary
graphics drivers in the Linux kernel. I am with the interpretation by
Linus Torvalds that GPL code that is linked to independent (!)
proprietary code does not infect this proprietary code, which is just
common sense. If however, you build a system that depends on GPL
components and you distribute your system, your additions must be
released as GPL. So it is not as easy as "no proprietary stuff" ;-)

In any case, Genode Labs offers proprietary licensing options in
addition to the GPL version of Genode FX. For using Genode FX in a
proprietary product, I suggest to contact Genode Labs directly.

Regards
Norman

Article: 134734
Subject: Re: Genode FPGA graphics project launched
From: Jon Beniston <jon@beniston.com>
Date: Thu, 28 Aug 2008 02:33:19 -0700 (PDT)
Links: << >>  << T >>  << A >>
> if you claim that then you can equally force Xilinx to release source
> code of the microblaze
> because the mb gcc is GPL licensed and not LPGL licensed

Not at all. GCC is not linked with Microblaze.

> not always ALL project sources are needed to be made public if GPL
> based part are
> used in the project

Correct. Its only if they are linked together.

> depend how you define project and library
> i can say its ALL one projects and microblaze is one VHDL library what
> is linked to the
> stuff compiled with GPL licensed tools, so microblaze also needs to be
> GPL, etc..

I'm not refering the s/w parts of this project - but the VHDL/Verilog
core that gets linked in.

> but in generic the GPLxxx stuff is not really applicable today for
> FPGA ip cores and related stuff

It is if IP cores are being released under the GPL.

Jon

Article: 134735
Subject: Re: Genode FPGA graphics project launched
From: Jon Beniston <jon@beniston.com>
Date: Thu, 28 Aug 2008 02:41:20 -0700 (PDT)
Links: << >>  << T >>  << A >>
> That discussion is going on for ages, for example about binary
> graphics drivers in the Linux kernel. I am with the interpretation by
> Linus Torvalds that GPL code that is linked to independent (!)
> proprietary code does not infect this proprietary code, which is just
> common sense.

Well, that argument is based on the fact that the proprietary code
isn't statically linked. That is not the case in an FPGA or ASIC. Much
easier to just use the LGPL so there is no confusion, IMHO.

Jon

Article: 134736
Subject: Re: Timing analyser
From: knight <krsheshu@gmail.com>
Date: Thu, 28 Aug 2008 03:11:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 28, 2:18 pm, "Symon" <symon_bre...@hotmail.com> wrote:
> "knight" <krshe...@gmail.com> wrote in message
>
> news:01250168-8d89-41c3-8c31-7fced56fcc62@m36g2000hse.googlegroups.com...
>
> > Hi
>
> > Actuallty U1/count_or00001 is a [FG] which sources more than 20
> > FlipFlops reset ( which i can see in floorplanner).
> > And the driving net is  U1/count_or0000.( this should source more than
> > 20 FFs)
> > Then why is the fanout given as 11 ..? (Please refer to * in the
> > report)
> > Shouldnt it be greater than 20..?
>
> Sir Knight,
> Have a look at the net in FPGA editor. I guess that two FFs in a slice get
> fed from a single pin.
> HTH., Syms.

thank you...

Article: 134737
Subject: Re: Saving PAR Constraints
From: knight <krsheshu@gmail.com>
Date: Thu, 28 Aug 2008 03:14:55 -0700 (PDT)
Links: << >>  << T >>  << A >>

> Hi,
> You can open the Place and Route design in the FloorPlanner.
> Go to Floorplan Menu -> Replace All with placement . This will copy
>
> Lux


Thank you that solved it...

Article: 134738
Subject: Re: Genode FPGA graphics project launched
From: David Brown <david@westcontrol.removethisbit.com>
Date: Thu, 28 Aug 2008 12:37:14 +0200
Links: << >>  << T >>  << A >>
Jon Beniston wrote:
>> That discussion is going on for ages, for example about binary
>> graphics drivers in the Linux kernel. I am with the interpretation by
>> Linus Torvalds that GPL code that is linked to independent (!)
>> proprietary code does not infect this proprietary code, which is just
>> common sense.
> 
> Well, that argument is based on the fact that the proprietary code
> isn't statically linked. That is not the case in an FPGA or ASIC. Much
> easier to just use the LGPL so there is no confusion, IMHO.
> 

It's *not* easier to use the LGPL - it is almost equally unsuitable. 
The GPL says (roughly) that any code that is directly linked to the 
GPL'ed code must also be GPL'ed.  You can't use GPL'ed IP and non-GPL'ed 
IP in the same FPGA.

The LGPL is a little lighter - it allows you to link the LGPL'ed code 
with non-GPL'ed code as long as anyone with the binary is able to get 
the source code to the LGPL part, modify it, re-link it, and use the new 
version.  This is fine for things like dynamically linked libraries on a 
desktop OS (that's what it was designed for), but hardly practical for 
FPGA IP!

A better choice of license would be what is known as a "modified GPL" or 
"GPL with exception" license (or the very similar Mozilla Public 
License).  Here the GPL is explicitly modified to apply only to the 
source files provided - you are free to link them in any way to any 
other modules under any other license.  This basically means you can use 
the modified GPL files as you like, but if you change them you have to 
give these changes back to the community.

See <http://www.freertos.org/a00114.html> for an example of this for an 
embedded RTOS.

Article: 134739
Subject: How to disable the static routing to cross through the PRR?
From: grant0920 <grant0920@gmail.com>
Date: Thu, 28 Aug 2008 06:42:39 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi! Everyone:

EA PR design flow can allow signals (routes) in the base design to
cross through a partially reconfigurable region without using a bus
macro. Howevr, can I disable the operation? Thanks!

BR,
hunag

Article: 134740
Subject: Re: Genode FPGA graphics project launched
From: "MikeWhy" <boat042-nospam@yahoo.com>
Date: Thu, 28 Aug 2008 09:30:58 -0500
Links: << >>  << T >>  << A >>
"Jon Beniston" <jon@beniston.com> wrote in message 
news:0d15ddf8-ebfd-4863-857d-3f4208728cc2@25g2000hsx.googlegroups.com...
> On 28 Aug, 08:27, nfeske <norman.fe...@genode-labs.com> wrote:
>> Hi Jon,
>>
>> > Looks interesting. Would the LGPL license be more appropriate though?
>> > For example, can you legally distribute a project based on the GPLed
>> > Genode that also uses MicroBlaze/NIOS, as doing so would presumably
>> > require you to provide the MicroBlaze source as well, which will
>> > obviously be a problem.
>>
>> According to the License text, the terms about the modification and
>> distribution of GPL'ed source code apply only to derivative work,
>> which is work that takes GPL source code as a starting point. The
>> Microblaze is clearly not derived work because it does not depend in
>> any way on the components Genode FX provides.
>
> Using GPLed code means that all code in a project must be open source.
> No proprietary stuff. Anything that uses Genode is a derived work. If
> you want to allow use with proprietary code, then the LGPL should be
> used.
>
> See here: http://www.gnu.org/philosophy/why-not-lgpl.html
>
> "The GNU Project has two principal licenses to use for libraries. One
> is the GNU Lesser GPL; the other is the ordinary GNU GPL. The choice
> of license makes a big difference: using the Lesser GPL permits use of
> the library in proprietary programs; using the ordinary GPL for a
> library makes it available only for free programs."

Yes, and it seems pretty clear. The code you build on top of Genode is 
GPL'ed. The underlying stuff that Genode in turn uses -- Microblaze, or even 
the FPGA fabric -- is not. The LGPL would differ by allowing your code, 
which uses Genode, to remain proprietary. The situation is clearer to see in 
more "traditional" software projects. For example, distributing a GPL'ed 
library doesn't infer also distributing the Windows operating system source.



Article: 134741
Subject: Re: Mass storage device on ML403 board
From: "MM" <mbmsv@yahoo.com>
Date: Thu, 28 Aug 2008 10:48:31 -0400
Links: << >>  << T >>  << A >>
"G. Carvajal" <gcarvajalb@gmail.com> wrote in message 
news:81ddad66-d25c-413b-9d90-11b6f563b2d4@b1g2000hsg.googlegroups.com...
>
> Currently I'm running the test in stand alone configuration. Some
> sugestions said that maybe we can try using Linux instead.

Another alternative would be eCos. There is a port available for ML403. I 
haven't tried it myself, so I am not sure if it has the specific drivers you 
need, but overall I think it is more suitable for an embedded application. 
Xilinx kernel has a lot of bugs, especially when it comes to multithreading, 
so it's no surprising that the system using it is unstable.

/Mikhail 



Article: 134742
Subject: Re: Genode FPGA graphics project launched
From: Jon Beniston <jon@beniston.com>
Date: Thu, 28 Aug 2008 07:58:04 -0700 (PDT)
Links: << >>  << T >>  << A >>
> > "The GNU Project has two principal licenses to use for libraries. One
> > is the GNU Lesser GPL; the other is the ordinary GNU GPL. The choice
> > of license makes a big difference: using the Lesser GPL permits use of
> > the library in proprietary programs; using the ordinary GPL for a
> > library makes it available only for free programs."
>
> Yes, and it seems pretty clear. The code you build on top of Genode is
> GPL'ed. The underlying stuff that Genode in turn uses -- Microblaze, or even
> the FPGA fabric -- is not.

If MicroBlaze was a hard-core, then maybe I'd agree. However, as a
soft-core, to me, it's the same as linking with a library.

Can a GPLed program run on a proprietary CPU and O/S? Yes. Can it link
in a proprietary library? No.

I would have thought the logical conclusion would therefore be that a
GPLed FPGA bitstream can run on a proprietary FPGA, but can't link in
proprietary soft IP cores.

Jon

Article: 134743
Subject: Re: Genode FPGA graphics project launched
From: Jon Beniston <jon@beniston.com>
Date: Thu, 28 Aug 2008 08:01:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
> The GPL says (roughly) that any code that is directly linked to the
> GPL'ed code must also be GPL'ed. =A0You can't use GPL'ed IP and non-GPL'e=
d
> IP in the same FPGA.

Ok, I think we agree here.

> The LGPL is a little lighter - it allows you to link the LGPL'ed code
> with non-GPL'ed code as long as anyone with the binary is able to get
> the source code to the LGPL part, modify it, re-link it, and use the new
> version. =A0This is fine for things like dynamically linked libraries on =
a
> desktop OS (that's what it was designed for), but hardly practical for
> FPGA IP!

You don't have to supply the modified code with the FPGA though. I'm
sure a web download would be suitable.

> A better choice of license would be what is known as a "modified GPL" or
> "GPL with exception" license (or the very similar Mozilla Public
> License). =A0Here the GPL is explicitly modified to apply only to the
> source files provided

What happens if someone modifies a file to use a function that is in a
new file though? Do they have to provide this?

Jon


Article: 134744
Subject: Re: Mass storage device on ML403 board
From: linnix <me@linnix.info-for.us>
Date: Thu, 28 Aug 2008 08:13:08 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 28, 12:13 am, "G. Carvajal" <gcarvaj...@gmail.com> wrote:
> Hi there,
>
> I need to implement a mass storage device on this board. My first
> approach was using the xilfatfs library for saving the data on a CF
> memory, but I'm facing a lot of problems with that. The system turns
> pretty unstable, and after some weeks trying to fixed it, we can't
> figured out where is the problem. The only guess is that there is a
> bad memory management from the xilfatfs library functions.
>
> Currently I'm running the test in stand alone configuration. Some
> sugestions said that maybe we can try using Linux instead. However, I
> was making some research and I couldn't find drivers for using the CF
> card or the USB port with a mass storage device. Have anybody tried to
> do this before? Do you know if there are drivers that supports these
> characteristics?

You don't need drivers.  IDE-CF support is build-in the kernel.  Same
for USB mass storage.


Article: 134745
Subject: Re: need fast FPGA suggestions
From: rickman <gnuarm@gmail.com>
Date: Thu, 28 Aug 2008 08:30:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 27, 5:45 pm, Jon Elson <el...@wustl.edu> wrote:
> Andrew FPGA wrote:
> >>So, you think a 13-bit counter feeding a 13-bit identity comparator will
> >>work at 250 MHz?
>
> > Others have said it may be possible but what they fail to acknowledge
> > is the large amount of extra design effort and care required to get
> > there. 250 MHz is really pushing the limits in spartan 3e in my
> > experience. You may have to work very hard to get there: for example I
> > have just finished a distributed arithmetic filter design, that has
> > only 1 LUT level between flops and after a lot of effort I got it to
> > run at 206 MHz in a sp3 1600e. I can see how to get to 220MHz, but
> > beyond that I don't know. The longest carry chain is 10 bits.
>
> > I had to bypass synthesis and instantiate xilinx primitives directly
> > to gaurantee my logic was implemented in 1 LUT level. Then I had to
> > manually floorplan the design - placing each flop with the
> > corresponding LUT by hand( I uses RLOC's embedded in the VHDL source).
> > The automatic placer didn't always place the LUT with the FLOP so you
> > end up with 2 routes which kills the timing completely.
>
> Yes, with 64 instantiations of the circuit on the FPGA, I really DON'T
> want to deal with this!
>
>
>
> >>Yeah, I really don't think we can handle $2000 IC's.  This isn't a real
> >>production project, we might build 5 of them at a time, but we are still
> >>cost-sensitive.
>
> > If its such low volumes just take the unit cost hit and move to a
> > Virtex part. How valuable is your time?
>
> Yes, I think you are right, and I greatly appreciate the data points
> about the 206 MHz and the 10-bit carry.  The circuit I need to implement
> is REALLY simple, but gets a bit more complicated when you add in the
> logic to handle the DDR.  The SERDES components in the Virtex look like
> they would be ideal to handle this, and instead of only having an X2
> option with DDR, this makes an X8 option nearly as simple.  The part
> cost, all by itself, is not that terrible, the smaller Virtex chips are
> around $200.  The other problem, however, is we have no capability or
> experience with BGAs, and would have to send them out.  That at least
> doubles the cost!

You don't have to use Virtex to get SERDES.  The low cost Lattice
family has SERDES and should be able to do what you are looking for at
a *much* lower price.

Rick


Article: 134746
Subject: Re: need fast FPGA suggestions
From: Jon Elson <jmelson@wustl.edu>
Date: Thu, 28 Aug 2008 11:01:57 -0500
Links: << >>  << T >>  << A >>


John_H wrote:
> On Aug 27, 2:45 pm, Jon Elson <el...@wustl.edu> wrote:
> 
>>Yes, I think you are right, and I greatly appreciate the data points
>>about the 206 MHz and the 10-bit carry.  The circuit I need to implement
>>is REALLY simple, but gets a bit more complicated when you add in the
>>logic to handle the DDR.  The SERDES components in the Virtex look like
>>they would be ideal to handle this, and instead of only having an X2
>>option with DDR, this makes an X8 option nearly as simple.  The part
>>cost, all by itself, is not that terrible, the smaller Virtex chips are
>>around $200.  The other problem, however, is we have no capability or
>>experience with BGAs, and would have to send them out.  That at least
>>doubles the cost!
>>
>>Thanks again for the info!
> 
> 
> 1) The Virtex is a good way to go; the SERDES will work for you as
> long as your minimum delays are met (same is true of shorter delay DDR
> version).
> 2) I thought you had 32 channels
What we have is 32 inputs.  Each input starts an independent and 
individually adjustable delay, at the end of that delay a pulse of a 
settable width comes out.  So, the delay and the width circuit are 
essentially digital one-shots, and basically the same.  The only 
difference would be the delay has an asynchronous input, the width is 
totally synchronous.

> 3) One instantiation is almost the same as 64 in complexity.  It's one
> lone module that produces the results for each instance.
As long as you don't need to go into the chip viewer and manually route 
anything to meet timing, yes.  I REALLY do not want to have to do that, 
as Andrew apparently needed to do on a Spartan 3 project.

> 4) BGAs can give growing pains, but it's the industry's current sweet-
> spot.  If not now, than a few more months down the road.
> 
> I'd personally be happy to crank out a design like this in the
> Spartan3x series, but for a 5-up production the added speed and
> functionality of the Virtex is a good win.

Well, given the serdes function of the Virtex, maybe we can go 1 ns 
input and output resolution, with only 125 MHz clock on the 
counter/comparator.  My boss would really love that.  The smaller Virtex 
seem to come in a 1mm-pitch BGA, maybe I can even learn how to do that 
myself.  Since the balls are only around the perimiter, it might be 
visibly inspectable.  I'll have to do more research to find out what is 
practical.

Jon


Article: 134747
Subject: Re: need fast FPGA suggestions
From: Jon Elson <jmelson@wustl.edu>
Date: Thu, 28 Aug 2008 11:06:32 -0500
Links: << >>  << T >>  << A >>


Jim Granville wrote:
> John Larkin wrote:
> 
>> Oh, 32 separate triggers. Stick with analog ramps?
>>
>> Some of the LVDS line receivers make might fine fast and cheap
>> comparators, duals even. So could probably do it all in cmos these
>> days, fairly simple stuff.
>>
>> Trigger fires flipflop, turns ramp loose; ramp drives two comparators,
>> which drive a logic gate to make rising/falling output edges. 2nd
>> comparator clears flipflop. 64 DAC channels program the mess, not bad
>> if you use serial octal dacs. Figure 2 square inches per channel to be
>> generous, so it's an 8x8" board.
> 
> 
> Analog is a candidate, but the OP mentioned a 100:1 dynamic range.
> Maybe some range-sw caps ?
> 
Well, it is all designed and the board is layed out.  I used the AD 
CMP603 single fast comparator.  A bear to mount, but a very fine chip 
for the purpose.  It DOES use 2 range switching caps, plus stray 
capacitance as the lowest cap value, plus 2 selections of 
current-programming resistor.

THEN, my boss said -- "Hey, couldn't you do that with an FPGA?"

> Anyone seen Vos vs Common Mode voltage plots for LVDS channels
> in FPGAs ? Cross talk figures ?
I guess you could measure it yourself.

Jon


Article: 134748
Subject: Re: Genode FPGA graphics project launched
From: "MikeWhy" <boat042-nospam@yahoo.com>
Date: Thu, 28 Aug 2008 11:24:30 -0500
Links: << >>  << T >>  << A >>
"Jon Beniston" <jon@beniston.com> wrote in message 
news:9f7da391-948c-48d2-a44c-e8abd1d859c4@m45g2000hsb.googlegroups.com...
>> > "The GNU Project has two principal licenses to use for libraries. One
>> > is the GNU Lesser GPL; the other is the ordinary GNU GPL. The choice
>> > of license makes a big difference: using the Lesser GPL permits use of
>> > the library in proprietary programs; using the ordinary GPL for a
>> > library makes it available only for free programs."
>>
>> Yes, and it seems pretty clear. The code you build on top of Genode is
>> GPL'ed. The underlying stuff that Genode in turn uses -- Microblaze, or 
>> even
>> the FPGA fabric -- is not.
>
> If MicroBlaze was a hard-core, then maybe I'd agree. However, as a
> soft-core, to me, it's the same as linking with a library.

If that were so, Genode would be required to GPL Microblaze, and our 
troubles would already be solved. We would just refer everyone else to 
Genode for the Microblaze code.

>
> Can a GPLed program run on a proprietary CPU and O/S? Yes. Can it link
> in a proprietary library? No.
>
> I would have thought the logical conclusion would therefore be that a
> GPLed FPGA bitstream can run on a proprietary FPGA, but can't link in
> proprietary soft IP cores.

Is the intent of the GPL to prohibit physical distribution on the same media 
as proprietary components? I think not. I can store GPL components on the 
same hard disk as I store unrelated components, proprietary or otherwise. 
Their presence in the same bitstream ... is complicated by the difference 
between general computing and embedded systems. I'm tending to agree with 
you that (my superficial understanding of) the license terms leaves it gray 
and muddy.

If a proprietary component puts a signal on a wire, and I arranged for a 
GPL'ed component to read that signal, am I in violation of the GPL? Does 
that constitute "linking with"?

If my GPL'ed component reads signals from disparate sources, proprietary or 
otherwise, would I be in violation of the GPL by generating signals 
specifically targetted for the GPL'ed GUI?

If I sell a proprietary solution that generated signals compatible with a 
GPL component, would the end user be in violation of the GPL by "linking" 
the two into a single bitstream?

For the same proprietary system, is it a violation of the GPL if it came 
already "linked" with the GPL component in a single bitstream?



Article: 134749
Subject: Re: need fast FPGA suggestions
From: John_H <newsgroup@johnhandwork.com>
Date: Thu, 28 Aug 2008 12:11:00 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 28, 8:30=A0am, rickman <gnu...@gmail.com> wrote:
>
> You don't have to use Virtex to get SERDES. =A0The low cost Lattice
> family has SERDES and should be able to do what you are looking for at
> a *much* lower price.

While it's true the 3+Gb/s high speed serial channels are available in
the Lattice parts (my first Lattice design has started in the ECP2M -
yay!) the SERDES referred to in the Virtex parts for these posts are -
unless I'm sincerely mistaken - the serializer/deserializer elements
built into the general IOBs.  The standard I/Os end up with 800Mb/
s-1Gb/s data rates (pulling these numbers from memory) with a simpler
interface than the MGTs or similar RocketIO that can far exceed the
general I/O data rates.

Even in the lattice part, 32 channels of receive and 32 channels of
transmit is costly in the 3Gb/s SERDES channels.

- John_H



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