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 95700

Article: 95700
Subject: Re: encryption
From: yusufilker@gmail.com
Date: 25 Jan 2006 08:14:11 -0800
Links: << >>  << T >>  << A >>
> Don't confuse 8kHz sampling rate with 8kb/s data rate.  They are very
> different concepts!


Rigth . it is just a typo .. 8x8 = 64kbps at least. thanks


Article: 95701
Subject: Re: Mistake in Xilinx dsp-book.pdf?
From: Holger Blum <usenet0106@kennsch.net>
Date: Wed, 25 Jan 2006 17:14:49 +0100
Links: << >>  << T >>  << A >>
Hello Brian!

Brian Drummond wrote:

> On Sat, 14 Jan 2006 23:00:05 +0100, Holger Blum <usenet0106@kennsch.net>
> wrote:
> 
> 
>>Hello!
>>
>>While working with a MAC-FIR I came across an equation in Xilinx'
>>DSP-book (http://www.xilinx.com/publications/books/dsp/dsp-book.pdf)
>>which seems to be wrong in my eyes.
>>
>>On page 65 equation 4.4 for the generic saturation level says
>>Output width = ceil(log2(2^(b-1)*2^(c-1)*N))+1
>>Where b/c are the numbers of data/coefficient bits and N is the filter
>>length.
>>
>>This formula is, apart from a missing parenthesis, ok, but the next one
>>for known coefficients says
>>Output width = ceil(log2(2^(b-1)*abs(sum(coef))*N))+1
>>
>>Again missing right parenthesis and the N is in my eyes wrong, because
>>it is already included in the sum of coefficients. Could anyone approve
>>this? I have to cite this paper in a thesis in lack of another source
>>for this equation (though it seems to be obvious, but I have to be sure).
> 
> 
> The coefficients can be both positive and negative, and (for a unity
> gain filter) will typically sum to 1, not N.

I know. But this formula uses already scaled and quantized coefficients,
so they sum up to a much higher number which then can be taken to
determine the actual width of the output signal (for a DC input signal).
In my design I have achieved unity gain by scaling the coefficients for
an integer number of used bits and picking the desired active bits from
the full-precision output. I am new to DSP on FPGA, but I think, that
this is the right way.

> Incidentally, counting the parentheses, I make it 5x( and 5x) in the
> above equation; where is the missing one?

I felt so free to correct these mistakes. In the .pdf you could see the
wrong equation.

Regards,
Holger


Article: 95702
Subject: Re: encryption
From: yusufilker@gmail.com
Date: 25 Jan 2006 08:21:17 -0800
Links: << >>  << T >>  << A >>

allanherriman@hotmail.com yazdi:
> And the low noise preamp, and the low pass filter and power amp for the
> speaker, and the DSP-based acoustic echo cancellation, and the analog
> noise generator (for the keys) and the controlling microprocessor (if
> not using the DSP chip for this) and the power supply components, and
> ... and ... and.
>
> Naturally, one leaves out some irrelevant details.
>
> Regards,
> Allan
> P.S. how did you know it was a sunny day here?

Device has its own speaker (and related dsp functions, power, power amp
etc).
LNA, analog LPF, no need to control it is freee running continuous
process. 
How to enter encryption keys still thinking about it..


Article: 95703
Subject: Re: encryption
From: "Antti Lukats" <antti@openchip.org>
Date: Wed, 25 Jan 2006 17:21:26 +0100
Links: << >>  << T >>  << A >>
<yusufilker@gmail.com> schrieb im Newsbeitrag 
news:1138205581.867274.248620@g43g2000cwa.googlegroups.com...
>
> Antti Lukats yazdi:
>> <yusufilker@gmail.com> schrieb im Newsbeitrag
>> news:1138197217.486165.248730@z14g2000cwz.googlegroups.com...
>> > thanks for your replies, I have to give more details
>> >
>> > It is not analog channel . It is digital and it is not easy to access
>> > to software/hardware , may be only to hardware that  mic-A/D conv
>> > part.)
>> > The device encrypts data BUT i do not trust encrypted data. becouse it
>> > is already listened (like internet = do you trust in your IE :)
>> > If I encrypt data in the device's microprocessor it can be recognized
>> > or at least overwritten by an software upgrade remotely etc...
>> >
>> > So I will add external circuit if i can.those A/D and D/A s required
>> > for this.
>> >
>> > Crosstalk can be a problem but how much i can not guess. i will insert
>> > a small circuit  between mic and host A/D conv.
>> > I am aware multiple A/Ds will generate too much noise but it is
>> > acceptable.
>> >
>> >
>> > voice like signal = same freq with original voice, same data dept, but
>> > just scrambled / I will feed encrypted voice like signal into device's
>> > A/D. I will remove the original mic/ sorry for bad english.
>> >
>> >
>> > no need for compression,  bandwidth is ok.  voice is  8kbps\ scrambled
>> > voice is also 8kbps \ device can send both of them without caring.
>> >
>>
>> this is exactly the most complicated case. if you want the encrypted 
>> voice
>> to be transmitted over the same analog channel, (eg feed it into AD) then
>> it is VERY VERY complicated to get it done right.
>>
>> in other words you can forget doing it.
>>
>> --
>> Antti Lukats
>> http://www.xilant.com
>
> Hi Antti,
>
> everything is naturally analog.
>
> But I did not say the channel is analog. It is digital channel.
>
> I use very small part of the device = just want to insert my circuit
> between microphone and A/D conv.
>
> my circuit = A/D+fpga+D/A    it seems very simple to me.
>
> (ok I pass LNA, LPF, etc but still simple)
>
> transmitting and receiving done by the device. every kind of noise
> reduction, crosstalk issues already handled by the device.
> OR do not I understand what you mean?
>

receiving voice converted from analog domain, encrypting in digital domain 
and converting into analog domain to be transmitted over an analog channel 
of the same bandwidth is not trivial at least. It is not something I would 
call 'simple'. Our mileage may vary, but I doubt there are anyone who would 
say 'simple' about transmitting encrypted voice over low bandwith analog 
media. If you think its simple go ahead and do it. Why wasting timing 
talking about something that is simple? My advice still is that it is of 
such complexity that you should forget it. If you do it wrong then it will 
be either not secure or not reliable. Doing it possible isnt so complex, but 
being secure, reliable without quality loss or analog bandwidth increase is 
REALLY complex task.

-- 
Antti Lukats
http://www.xilant.com








Article: 95704
Subject: Re: open source fpga programmer programs
From: fpga_toys@yahoo.com
Date: 25 Jan 2006 08:27:57 -0800
Links: << >>  << T >>  << A >>

Eli Hughes wrote:
> Don't waste your time.  Vendor's spend a *VERY* long time working out
> bugs in their software.  With the level of complexity of an FPGA, you
> don't want to waste time with buggy software that is developed in
> someone else's spare time.  All of the actually chip programming,
> routing stuff is vendor locked(for good reason), so your out of luck on
> that.
>
> That being said, Xilinx does offer their software for Linux. It is not
> opensource but it does give you a non-windows alternative.

Eli ... the open source community does as well. It's rather an insult
against those of us that do volunteer our time toward open source
project to brashly brand open source that way.

Consider that Xilinx believes the Linux is a stable platform for it
tools,
is it not? Consider thart Xilinx uses the GCC compiler for it's PPC
support, does it not? Consider that Xilinx uses the GNU libraries on
the PPC, does it not?

The only thing here that is wrong, is that Xilinx leaches off the backs
of open source developers, then asserts prioprietary rights to open
source efforts to do a BETER job at place, route, and bit steam
generation. At least other mainstream corporations have the good
sense to both embrace open source in their product offerings, and
give back to the open source community at the same time.

See the what happened to JHDLBits thread.

John
FpgaC developer


Article: 95705
Subject: Re: Spartan-3 Starter Board
From: "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk>
Date: Wed, 25 Jan 2006 16:29:45 -0000
Links: << >>  << T >>  << A >>
Chris

You might want to have a look at our product Raggedstone1. It has the much 
larger XC3S400-4FG456C part fitted. Programming cable is included and card 
can be used in a PCI slot or stand-alone with the optional PCI I/O Header. 
Details here http://www.enterpoint.co.uk/moelbryn/raggedstone1.html.

John Adair
Enterpoint Ltd. - Home of Raggedstone1. The Low Cost Spartan-3 Development 
Board.
http://www.enterpoint.co.uk

<Chris.Gammell@gmail.com> wrote in message 
news:1138199130.162720.321920@g44g2000cwa.googlegroups.com...
> Hey All,
>
> Just wondering if anyone has tried out the Spartan-3 starter board
> offered on Xilinx's website (the 99 dollar one). I am a student
> developing a project on an FPGA and that seemed like the most cost
> effective option for me. Has anyone tried it? If so, how is the
> speed/capacity for your needs? How about the simplified JTAG interface,
> does that perform OK? Thanks in advance and I look forward to hearing
> from you.
>
> Chris
> 



Article: 95706
Subject: Re: encryption
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 25 Jan 2006 16:35:35 -0000
Links: << >>  << T >>  << A >>

"Antti Lukats" <antti@openchip.org> wrote in message 
news:dr88pm$kcp$01$1@news.t-online.com...
>
> receiving voice converted from analog domain, encrypting in digital domain 
> and converting into analog domain to be transmitted over an analog channel 
> of the same bandwidth is not trivial at least. It is not something I would 
> call 'simple'. Our mileage may vary, but I doubt there are anyone who 
> would say 'simple' about transmitting encrypted voice over low bandwith 
> analog media. If you think its simple go ahead and do it. Why wasting 
> timing talking about something that is simple? My advice still is that it 
> is of such complexity that you should forget it. If you do it wrong then 
> it will be either not secure or not reliable. Doing it possible isnt so 
> complex, but being secure, reliable without quality loss or analog 
> bandwidth increase is REALLY complex task.
>
> -- 
> Antti Lukats
> http://www.xilant.com
>
Antti,
Why can't you use this scheme? Rx voice -> digitise -> MP3 compression -> 
encrypt -> a plain old 56 kbps dial-up modem ?
Cheers, Syms. 



Article: 95707
Subject: Re: encryption
From: "Antti Lukats" <antti@openchip.org>
Date: Wed, 25 Jan 2006 17:40:14 +0100
Links: << >>  << T >>  << A >>
"Symon" <symon_brewer@hotmail.com> schrieb im Newsbeitrag 
news:43d7a88d$0$15784$14726298@news.sunsite.dk...
>
> "Antti Lukats" <antti@openchip.org> wrote in message 
> news:dr88pm$kcp$01$1@news.t-online.com...
>>
>> receiving voice converted from analog domain, encrypting in digital 
>> domain and converting into analog domain to be transmitted over an analog 
>> channel of the same bandwidth is not trivial at least. It is not 
>> something I would call 'simple'. Our mileage may vary, but I doubt there 
>> are anyone who would say 'simple' about transmitting encrypted voice over 
>> low bandwith analog media. If you think its simple go ahead and do it. 
>> Why wasting timing talking about something that is simple? My advice 
>> still is that it is of such complexity that you should forget it. If you 
>> do it wrong then it will be either not secure or not reliable. Doing it 
>> possible isnt so complex, but being secure, reliable without quality loss 
>> or analog bandwidth increase is REALLY complex task.
>>
>> -- 
>> Antti Lukats
>> http://www.xilant.com
>>
> Antti,
> Why can't you use this scheme? Rx voice -> digitise -> MP3 compression -> 
> encrypt -> a plain old 56 kbps dial-up modem ?
> Cheers, Syms.
>
you can - but doing that with an PLD isnt something I call simple ;)


-- 
Antti Lukats
http://www.xilant.com 



Article: 95708
Subject: Re: open source fpga programmer programs
From: Larry Doolittle <ldoolitt@localhost.localdomain>
Date: 25 Jan 2006 08:45:51 -0800
Links: << >>  << T >>  << A >>
On 2006-01-25, Eli Hughes <emh203@psu.edu> wrote:
> Dave Feustel wrote:
>> Are there any open source programs for programming fpgas?
>
> Don't waste your time.  Vendor's spend a *VERY* long time working out 
> bugs in their software.

"There are two ways of constructing a software design. One way is
to make it so simple that there are obviously no deficiencies
and the other is to make it so complicated that there are no
obvious deficiencies."
    - C A R Hoare
    
> With the level of complexity of an FPGA, you 
> don't want to waste time with buggy software that is developed in 
> someone else's spare time.  All of the actually chip programming, 
> routing stuff is vendor locked(for good reason), so your out of luck on 
> that.

In other words, "shut up and get back on the couch".

> That being said, Xilinx does offer their software for Linux. It is not
> opensource but it does give you a non-windows alternative.

"I won't run software written by cowards."
    - Adam Stiles, referring to software provided without source code

      - Larry

Article: 95709
Subject: Re: encryption
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 25 Jan 2006 16:47:03 -0000
Links: << >>  << T >>  << A >>

"Antti Lukats" <antti@openchip.org> wrote in message 
news:dr89le$mo5$01$1@news.t-online.com...
> "Symon" <symon_brewer@hotmail.com> schrieb im Newsbeitrag
>> Antti,
>> Why can't you use this scheme? Rx voice -> digitise -> MP3 compression -> 
>> encrypt -> a plain old 56 kbps dial-up modem ?
>> Cheers, Syms.
>>
> you can - but doing that with an PLD isnt something I call simple ;)
>
>
OK, I understand! And I agree. :-)
Cheers, Syms. 



Article: 95710
Subject: Re: So what happened to JHDLBits?
From: fpga_toys@yahoo.com
Date: 25 Jan 2006 08:56:31 -0800
Links: << >>  << T >>  << A >>

fpga_toys@yahoo.com wrote:
> So, Xilinx let this team proceed, gained a lot of publicity from it as
> marketing
> collaterial, and then dashed the teams hopes of taking it open source.
> I doubt
> the team would have partnered with Xilinx had the outcome been clearly
> stated
> up front. They put a lot of energy into the project, then were told to
> shutup and
> walk away.
>
> Much of what the FpgaC project needs to support compile, load, and go
> for Xilinx
> product is trapped in this project, with a clear warning from Xilinx to
> stay clear.
> The likely outcome is to focus on other vendors which are more willing
> to allow
> open source investment in RC technologies which support their products.


I should probably add that Xilinx leaches a hell of a lot of value off
open
source by using Linux as a host platform for it's tools, GCC at the
main
production compiler for PPC core software, GNU for the libraries for
PPC, and Linux in several forms as host operating systems for it's
product offerings.

It's probably worth writing Austin, Peter, and the other regular usenix
posters
from Xilinx and making it clear just how much Xilinx benefits from open
source, the Xilinx market created by open source, and the developers
which
frequently volunteer their time supporting Xilinx open source use.

And then suggest that they take their thumb off the JHDLBits project,
and
start doing a better job of contributing back to the open source
community.
If that isn't enough to get their attention, maybe switching design
wins to
Altera and letting them know why.


Article: 95711
Subject: Re: encryption
From: allanherriman@hotmail.com
Date: 25 Jan 2006 08:58:49 -0800
Links: << >>  << T >>  << A >>
Jan Panteltje wrote:
> On a sunny day (25 Jan 2006 05:28:15 -0800) it happened
> allanherriman@hotmail.com wrote in
> <1138195695.581945.80890@g44g2000cwa.googlegroups.com>:
>
> >And the low noise preamp, and the low pass filter and power amp for the
> >speaker, and the DSP-based acoustic echo cancellation, and the analog
> >noise generator (for the keys) and the controlling microprocessor (if
> >not using the DSP chip for this) and the power supply components, and
> >... and ... and.
> >
> >Naturally, one leaves out some irrelevant details.
>
> You wrote:
> <quote>
>  This would be the minimum required to make a "professional-grade" voice
>  encryptor:
> <quoted>
> So tha twas not very professional, as i tshows no knowledge of signal processing.
>
>
>
> >Regards,
> >Allan
> >P.S. how did you know it was a sunny day here?
> I only know you reply to me because of the headers, you forgot to qute
> what and who you are replying to.
> Not very professional either.
>
> As for the sunny day, try a suitable reference frame.

Hi Jan,

I don't understand these personal attacks.  What did I do to you?  As
for your "no knowledge" comment, my body of work in a number of fields
(incl. signal processing) speaks for itself and needs no defending.

Have you considered switching to decaf?

Regards,
Allan


Article: 95712
Subject: Re: custom ip using EDK
From: "Eric" <dasani8888@hotmail.com>
Date: 25 Jan 2006 09:00:56 -0800
Links: << >>  << T >>  << A >>
Hi,
Read/Write processes are generated by Xilinx EDK when I used
create/import peripheral wizard. I only modified the write process, and
wrote an adding function. Sorry I removed the comments when I posted
the code. But here it is:

  --    Bus2IP_WrCE or   Memory Mapped
  --       Bus2IP_RdCE   Register
  --            "1000"   C_BASEADDR + 0x0
  --            "0100"   C_BASEADDR + 0x4
  --            "0010"   C_BASEADDR + 0x8
  --            "0001"   C_BASEADDR + 0xC

  slv_reg_write_select <= Bus2IP_WrCE(0 to 2);
  slv_reg_read_select  <= Bus2IP_RdCE(0 to 2);
  slv_write_ack        <= Bus2IP_WrCE(0) or Bus2IP_WrCE(1) or
Bus2IP_WrCE(2);
  slv_read_ack         <= Bus2IP_RdCE(0) or Bus2IP_RdCE(1) or
Bus2IP_RdCE(2);

I know I have both reg0 and reg1 values correct from the terminal. But
I can't get the sum. Thanks!


Article: 95713
Subject: Re: porting linux on ml403
From: fpga_toys@yahoo.com
Date: 25 Jan 2006 09:11:46 -0800
Links: << >>  << T >>  << A >>

ramesh wrote:
> Hi All,
> Iam new to xilinx platfrom.
>
> I was trying to port open source linux on Ml403 board. i tried to

I should probably note that Xilinx leaches a hell of a lot of value off
open source by using Linux as a host platform for it's tools, GCC as
the main production compiler for PPC core software, GNU for the
libraries for PPC, and Linux in several forms as host operating systems
for it's product offerings.

It's probably worth writing Austin, Peter, and the other regular usenet
posters from Xilinx and making it clear just how much Xilinx benefits
from open source, the Xilinx market created by open source, and the
developers which frequently volunteer their time supporting Xilinx open
source use.

And then suggest that they take their thumb off the JHDLBits project,
and start doing a better job of contributing back to the open source
community.  If that isn't enough to get their attention, maybe
switching design wins to Altera and letting Xilinx sales know why.

The JHDLBits team boldly set out to provide open source Xilinx tools
before getting shut down by Xilinx.

References are a dead sourceforge project, and some papers:
http://www.ccm.ece.vt.edu/papers/poetter_2004_ERSA04_jhdlbits.pdf
http://www.ccm.ece.vt.edu/papers/poetter_2004_FPL04_jhdlbits.pdf

Plus see the teams thesis work:
http://www.ccm.ece.vt.edu/papers/

The wire data base, router, fpga simulator, and the main JHDLBits tools
are a valuable reconfigurable computing resource for the open source
community ... many hours of
effort by this team squashed by Xilinx


Article: 95714
Subject: Re: Xilinx padding LC numbers, how do you really feel about it?
From: Ray Andraka <ray@andraka.com>
Date: Wed, 25 Jan 2006 13:03:49 -0500
Links: << >>  << T >>  << A >>
fpga_toys@yahoo.com wrote:

> 
> you are not the only one that is suggesting that derating Xilinx parts
> 50% is the minimum rational target for an RTL based RC system on
> those platforms. I don't think this is acceptable long term, and very
> hard to justify. That Xilinx actively prevents alternative P&R and bit
> stream tools to improve an this, simply means they are not interested
> in better fit for their product line ... IE go away, we don't care
> about
> that market.
> 
> Thanks for clearly expressing this.
> 

Why is it so hard to justify.  One could argue that you can't use 100% 
of a microprocessor either.  Any given instruction leaves part of the 
microprocessor idle: it is impossible to use all of the features all of 
the time.  Why should you have different expectations of an FPGA?  As I 
pointed out before, you can get to the high utilization and high 
performance corner, but you are not likely to get there while also 
pushing the fast to compile and easy to use buttons.  FPGA design, at 
the core is digital logic design no matter how many fancy tools you 
throw at it.

The fact of the matter is that FPGAs offer many more degrees of freedom 
in the design than what is offered by a conventional computer.  The 
added degrees of freedom make them very powerful for efficient 
processing, but it also means that the design space has more things to 
trade-off to get to a particular corner of the design space (not to 
mention more ways to approach a particular problem which makes it harder 
for automated construction).  Getting into the density and performance 
corners requires more design effort.  No amount of wishing is going to 
change that fact. Designing to hit the high performance and high density 
corners is possible, but it isn't likely to happen when trying to also 
stay in the minimal effort and fast time to compile corners.

If you want to call that de-rating the FPGA, that's your perogative.  I 
don't see it as de-rating the FPGA, as the FPGA can and does meet the 
performance and density you are seeking, but at the price of design 
effort.  That is not de-rating, that is weighing the design trade-offs. 
  If you want to play in a particular corner, you need to make the 
concessions to get you there.  You can't cover all the corners at once, 
and that certainly isn't unique to FPGA design.  Which do you want more: 
fast compile times, ease of use, performance, density?  You can 
reasonably get two of these, any more than that is not going to get you 
into the corner.

Article: 95715
Subject: Re: Xilinx padding LC numbers, how do you really feel about it?
From: fpga_toys@yahoo.com
Date: 25 Jan 2006 10:27:01 -0800
Links: << >>  << T >>  << A >>

Ray Andraka wrote:
> Why is it so hard to justify.  One could argue that you can't use 100%
> of a microprocessor either.  Any given instruction leaves part of the
> microprocessor idle: it is impossible to use all of the features all of
> the time.

First, apples and oranges and cow pucky comparison. It's not about
leaving unused resources idle, it's about not idling used resources,
which is exactly the problem here. Good compilers get well inside of
99.x% efficiency for code to hardware fit in terms of the application
for most architectures. Even poor compilers tend to get better than a
90% fit. When it's only possible to get a 50%, or less fit, by your
standards in an fpga for the primary execution path netlist, that is a
HUGE derate. Most good compilers pack pipelines with very, very, very
few wasted cycles for nearly 100% hardware effieciency for the
application. The goal, is to reach similar efficient pipeline packing
on FPGA's, and waste few if any resources in the process. I agree with
your argument, that the existing Xilinx fpga's and tools will not yeild
close to 100%, and we need to derate that expectation that we carry
forward from traditional instruction set pipeline packing experience.
You are the Xilinx expert here, and if you claim less than 50% packing
efficiency with Xilinx product ... I'm not going to stand here and
argue with you about that.

I will argue, that given better integration to a different place and
route tool, such as that contained in JHDLbits, that FpgaC can do
significantly better than "less than 50% efficiency/utililization" of
LUT/FF based resources for a large number of unrolled loop
applications, such a finite difference modeling, RC5 code cracking, and
other dense unrolled loop pipelines which are common in the industry as
threaded/MPI/PVM multiprocessor applications.


Article: 95716
Subject: XO for Xilinx V2Pro MGTs
From: "Ron Huizen" <rhuizen@bittware.com>
Date: Wed, 25 Jan 2006 13:33:41 -0500
Links: << >>  << T >>  << A >>
Does anyone have experience using any oscillators for the MGTs on the V2Pro 
other than the two listed in Xilinx's app note (Epson and Pletronics)?

We've always used the Epson part (100, 125, or 156.25 MHz) in the past but 
now need an extended temp version  which they don't have, and unfortunately 
the Pletronics part, which does have an extended temp version,  has a 3.3V 
supply instead of the 2.5 supply like the Epson.

Ideally, we want a drop in for the Epson, which is a 6 pin 5x7 package, pin 
1 enable, 2.5V supply.  Issues or concern are termination and jitter.

------------
Ron Huizen
BittWare 



Article: 95717
Subject: Re: Xilinx padding LC numbers, how do you really feel about it?
From: "Andy Peters" <Bassman59a@yahoo.com>
Date: 25 Jan 2006 10:39:02 -0800
Links: << >>  << T >>  << A >>
fpga_toys@yahoo.com wrote:
> Ray Andraka wrote:
> > So my point is, the FPGA vendors give you the information they can about
> > power dissipation.  They can't know your design to provide you better
> > numbers without you actually simulating the post PAR design with vectors
> > that accurately reflect the actual usage.  For a general purpose board,
> > the board designer can limit the FPGA dissipation to whatever is safe
> > for the board cooling environment by using thermal diodes or power
> > supply current limits to avoid damage to the FPGA or board, and he can
> > do that without knowing anything about your design.  Isn't that a better
> > tree to bark up?
>
> So, my point is, and nobody seems to disagree, that it's unrealistic to
> assume that the devices can be 100% packed, use the marketing numbers
> for system design clock speeds, at a modest toggle rate, and not blow
> right thru the power the device can handle. Disagree?
>
> If not, then the device HAS TO BE DERATED from marketing numbers for RC
> use. Disagree?

I fail to understand how, as an FPGA application, "reconfigurable
computing" is somehow different (more resource intensive, more "high
performance," whatever) from an "application-specific" FPGA design.

After all, every FPGA engineer wants the best of everything:
lowest-cost part (which implies smallest/least amount of logic/best use
of resources), lowest power dissipation and of course the least amount
of engineering effort to meet those goals!

-a


Article: 95718
Subject: Re: open source fpga programmer programs
From: Eli Hughes <emh203@psu.edu>
Date: Wed, 25 Jan 2006 13:47:40 -0500
Links: << >>  << T >>  << A >>
fpga_toys@yahoo.com wrote:
> Eli Hughes wrote:
> 
>>Don't waste your time.  Vendor's spend a *VERY* long time working out
>>bugs in their software.  With the level of complexity of an FPGA, you
>>don't want to waste time with buggy software that is developed in
>>someone else's spare time.  All of the actually chip programming,
>>routing stuff is vendor locked(for good reason), so your out of luck on
>>that.
>>
>>That being said, Xilinx does offer their software for Linux. It is not
>>opensource but it does give you a non-windows alternative.
> 
> 
> Eli ... the open source community does as well. It's rather an insult
> against those of us that do volunteer our time toward open source
> project to brashly brand open source that way.
> 
> Consider that Xilinx believes the Linux is a stable platform for it
> tools,
> is it not? Consider thart Xilinx uses the GCC compiler for it's PPC
> support, does it not? Consider that Xilinx uses the GNU libraries on
> the PPC, does it not?
> 
> The only thing here that is wrong, is that Xilinx leaches off the backs
> of open source developers, then asserts prioprietary rights to open
> source efforts to do a BETER job at place, route, and bit steam
> generation. At least other mainstream corporations have the good
> sense to both embrace open source in their product offerings, and
> give back to the open source community at the same time.
> 
> See the what happened to JHDLBits thread.
> 
> John
> FpgaC developer
> 


My aim was not to insult.  I am aware of alot of quality open source 
applications.

I agree that Xilinx does use open source tools like GCC and what not 
because of their quality but I think open source FPGA tools may be a 
little different.  For it to work out, Xilinx would have to give away 
the gut of the parts so people could write applications properly.  This 
would pose an issue with other companies such as brand 'A' to just take 
their IP.  That is their business, to develop the best guts.


Sorry for the insult.

-Eli



Article: 95719
Subject: Re: Xilinx padding LC numbers, how do you really feel about it?
From: fpga_toys@yahoo.com
Date: 25 Jan 2006 10:57:45 -0800
Links: << >>  << T >>  << A >>

Andy Peters wrote:
> I fail to understand how, as an FPGA application, "reconfigurable
> computing" is somehow different (more resource intensive, more "high
> performance," whatever) from an "application-specific" FPGA design.
>
> After all, every FPGA engineer wants the best of everything:
> lowest-cost part (which implies smallest/least amount of logic/best use
> of resources), lowest power dissipation and of course the least amount
> of engineering effort to meet those goals!

In two ways ... it will be one to three orders of magnitude larger than
a hand written hardware design, and as such will not benefit normally
from low level optimization, placement, packing, routing enhancements
that a typical hardware design will get.  It WILL depend on the tools
to do a better than average fit automatically.

Second the life of an RC design will frequently be very short, and will
evolve. Hardware designs tend to live "forever" from a typical software
perspective ... as such hardware designs have a very strong incentive
to invest manual labor up front to get the best fit to hardware for
cost management .... that labor cost will then be amortized over the
life of many units. A typical RC program will have a total life span a
fraction of that, and is not likely to be frozen in time with large
scale hardware shipments so there is no large incentive to invest
effort toward optimizing a particular RC applicaion on hardware. There
is EVERY incentive to optimize tools to do a better job at hardware
fit, as those tools will have a long life and the effort amortizedf
over MANY RC applications.

The same argument, in analogy, is very few people invest the effort to
hand optimize assembly language fit for applications ... but it is
worth putting effort into optimizing the tool chain ... compilers, etc
until diminishing returns is reached.

Other than that, gates are gates.


Article: 95720
Subject: Re: help:dual-edge flip-flop possible using Verilog?
From: "Paul Marciano" <pm940@yahoo.com>
Date: 25 Jan 2006 11:04:01 -0800
Links: << >>  << T >>  << A >>

Peter Alfke wrote:
> The circuit is reliable, although the generated pulse width is
> determined by gate delays. But it is self-compensating, since the clock
> pulse will not end until the flip-flop has toggled. It's kind of
> clever, if I am allowed to say so...
> Peter Alfke

Peter,

Newbie question - I remember seeing an edge detector made up from a
single XOR gate and a few inverters to add a propagation delay, but no
registers.

Would such a circuit be equivalent to yours?  Any pros/cons either way?

Regards,
Paul


Article: 95721
Subject: Re: XO for Xilinx V2Pro MGTs
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 25 Jan 2006 11:19:55 -0800
Links: << >>  << T >>  << A >>
Ron,

Look for an LVDS output oscillator.

Then the matter of supply voltage does not matter.

LVDS is LVDS:  does not matter if it runs off of 2.5V, or 3.3V.

Austin

Ron Huizen wrote:

> Does anyone have experience using any oscillators for the MGTs on the V2Pro 
> other than the two listed in Xilinx's app note (Epson and Pletronics)?
> 
> We've always used the Epson part (100, 125, or 156.25 MHz) in the past but 
> now need an extended temp version  which they don't have, and unfortunately 
> the Pletronics part, which does have an extended temp version,  has a 3.3V 
> supply instead of the 2.5 supply like the Epson.
> 
> Ideally, we want a drop in for the Epson, which is a 6 pin 5x7 package, pin 
> 1 enable, 2.5V supply.  Issues or concern are termination and jitter.
> 
> ------------
> Ron Huizen
> BittWare 
> 
> 

Article: 95722
Subject: Re: open source fpga programmer programs
From: fpga_toys@yahoo.com
Date: 25 Jan 2006 11:27:50 -0800
Links: << >>  << T >>  << A >>

Eli Hughes wrote:
> I agree that Xilinx does use open source tools like GCC and what not
> because of their quality but I think open source FPGA tools may be a
> little different.  For it to work out, Xilinx would have to give away
> the gut of the parts so people could write applications properly.  This
> would pose an issue with other companies such as brand 'A' to just take
> their IP.  That is their business, to develop the best guts.

Gcc wasn't the greatest compiler in it's early days either, Nor was
linux
or the gnu libraries. Over time things get better with use and
community
commitment. Open source EDA will too.

FPGA EDA tools have been high dollar revenue producers ... $10K to
$100K
per seat license. Xilinx uses that revenue to pay programmers, which
have
every incentive to protect their jobs by blocking competitive
development of
similar tools. At the same time, they have very limited resources, and
can not
respond to all users needs, such as a totally different placement,
router, and
bitstream tool set for reconfigurable computing because there are not
established
high volume users asking for this feature set.

I can, and will, continue to say that the existing tool chain is
horrible for FpgaC to
interface to as it's a huge bottle neck for compile, load and go ...
and it's utilitization
of hardware resources really sucks unless you are willing to let it
work for several
days ... and often even then the results suck because it makes some
poor choices
very early that it will not rip up and replace.  FpgaC tends to produce
lots of very
regular mesh structures, which using very different placement/cost
algorithm can be
routed fast, on the fly, to a bit stream to support compile, load and
go operations
on the order of seconds, not hours  -- with a substantially better fit
than par simply
by retaining the mesh relationships rather than abandoning them. The
compiler by
it's very nature, tends to produce a few types of structures, which are
emitted with
very little change, over, and over, and over. By carefully optimizing
those emitted
structures, and fine tuning the place and route process to be optimized
for them, it
a much simplier problem than xilinx par is optimized for, and much,
much easiter
get better utilization as the end result is something similar to
dynamically generated
cores which are just replicated and routed togather.

The big difference, is that these structures are not pure macros/cores
... but are logic
blocks which the complier merges with adjacent blocks into packed LUTs.
So what
is output are not fixed regular structures in terms of pure
macros/cores, but mesh
structures of optimized logic pipelines. Xilinx par isn't tuned to
recognize these mesh
structures, and breaks them apart ... and other poor choices. Some
things which
FpgaC does as clear optimizations, also just drive par nuts ... like
clock enables to
reduce the depth of LUT based multiplexors and the need for FF feedback
for idle
states.  The result is that par separates the LUT and FF from each
other, then wastes
another LUT for pass thru, and burns routing resources/dynamic power in
the process.
Greatly complicating the FpgaC to optimize around par's faults is a
goose chase, since
it may do something completely different the next release and we will
waste a lot of
time optimizing FpgaC for each and every ISE release ... with a growing
number of
divergent hacks. Simply taking something like the JHDLBits wire
database and router
and fine tuning it for FpgaC is MUCH MUCH easier, and decouples us from
having
a different hack for every change in ISE. Plus we get compile, load,
and go times down
to seconds, instead of the minutes or hours that it takes par to do a
poor job.

We will put our efforts into supporting FPGA vendors that want our
help, and appreciate
the long term investment we are making into their products future, and
their companies
sales.


Article: 95723
Subject: Re: porting linux on ml403
From: Peter Ryser <peter.ryser@xilinx.com>
Date: Wed, 25 Jan 2006 11:33:15 -0800
Links: << >>  << T >>  << A >>
Hi Ramesh,

you might want to have a look at the following documents:
- XAPP765 (http://www.xilinx.com/bvdocs/appnotes/xapp765.pdf). This 
document describes on how to get started with EDK and the ML300 board. 
The approach for the ML403 board is the same
- UG080, pg. 37 (http://www.xilinx.com/bvdocs/userguides/ug082.pdf). 
This document contains a brief description on how to rebuild the Linux 
kernel for the ML403 board.

Start with rebuilding the reference design and Linux kernel for the 
ML403 board. All the necessary information can be found in the documents 
above and on 
http://www.xilinx.com/products/boards/ml403/reference_designs.htm

The Xilinx software drivers for the Linux peripherals have been released 
into the open source repository for the Linux PPC 2.4 kernel tree. This 
tree is picked up by various Linux distributions. Further, the MLD 
technology in EDK helps you to customize the Linux kernel for your 
particular hardware design.

At this time I recommend staying with the 2.4 Linux kernel as the 
support for ML300 (and the ML403) in the 2.6 kernel is very basic (UART 
only).

Another good source of information is the linuxppc-embedded mailing list 
(see http://ozlabs.org/mailman/listinfo). The latest developments wrt 
Linux kernel for the MLxxx boards is discussed there.

- Peter


ramesh wrote:

> Hi All,
> Iam new to xilinx platfrom.
> 
> I was trying to port open source linux on Ml403 board. i tried to
> follow the instructions in the below link.
> http://www.klingauf.de/v2p/index.phtml
> i was getting errors when i was running bZimage. the .elf file was not
> getting created.
> 
> Is there an alternative way of acheiving my goal.
> Kindly suggest.
> Thanks in advance.
> 
> Ramesh
> 


Article: 95724
Subject: Re: Spartan-3 Starter Board
From: "Jeff" <jeff.ward@gmail.com>
Date: 25 Jan 2006 11:45:52 -0800
Links: << >>  << T >>  << A >>
Chris,

I bought the S3 starter board last year for a VHDL senior class
project.  I implemented a 32-bit CPU in it, and demonstrated a program
which detected prime numbers on the 8-segment display.  The whole
design took about 90% of the chip, but it went smoothly, and for $99,
how can you beat it?!

However, like Antti said, today I would spring for the S3E for $149.
It has a larger FPGA, more RAM, and a couple more goodies on the board.
 The only downside is that they are newly released and you may have
trouble getting ahold of one.

Cheers,
-Jeff




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