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 114650

Article: 114650
Subject: Re: "Divide" a video line in two stripe
From: "jbnote" <jbnote@gmail.com>
Date: 22 Jan 2007 01:33:40 -0800
Links: << >>  << T >>  << A >>
Hello again,

> The simplest scheme would certainly be to use two async fifos of
> half-a-line each (one for each DVI output stream). The input stream
> feeds alternatively the first and the second fifo. You synchronize the
> get of the fifos when both have data: this allows you to get two
> synchronized output DVI streams with one line buffering.

Now that I think of it, even in this suboptimal case, your second fifo
only need to be a quarter line. It can start emptying as soon as data
is fed into it, at half the data rate. But then you get a half-line
delay between the input and output streams.

So for this scheme, the summary is:

* Synchronized output streams, one line delay costs 1 line buffering
* Synchronized output streams, half-line delay costs 3/4 of a line of
buffering
* Desynchronized output streams costs 1/2 line of buffering

JB


Article: 114651
Subject: Re: "Divide" a video line in two stripe
From: "Sylvain Munaut <SomeOne@SomeDomain.com>" <246tnt@gmail.com>
Date: 22 Jan 2007 01:37:57 -0800
Links: << >>  << T >>  << A >>

jbnote wrote:
> Hello,
>
> The simplest scheme would certainly be to use two async fifos of
> half-a-line each (one for each DVI output stream). The input stream
> feeds alternatively the first and the second fifo. You synchronize the
> get of the fifos when both have data: this allows you to get two
> synchronized output DVI streams with one line buffering.
>
> If you can desynchronize the DVI output streams, then a quarter line
> fifo for each output stream is sufficient (you don't have to wait for
> the other fifo to have elements in it to start emptying it, so by te
> time the input stream gets back to you, you already have half-emptied
> your first fifo).

As I said, I need to have a 1 line delay, because of sync with the DVI
timing, both input and output of my module must be in sync with it.
(well, withing a few clock cycles of pipeline ...)

And the two DVI outputs must be synchronous within a few ns ...


So with this scheme (two FIFO), the FIFO storing the the first half of
line would need to be bigger.
At the end of the line, both fifo would be full with the pixel of that
line. Then during the first half of the next line, at each clock cycle,
I would be reading 1 pixel, and pushing 2 pixels. And that for half a
line, so the first fifo would need to be 3/4 of a line and the second
one would need to be 1/2 a line. So I'm over my "quota" of 1 line of
video storage.


Sylvain


Article: 114652
Subject: Re: "Divide" a video line in two stripe
From: "jbnote" <jbnote@gmail.com>
Date: 22 Jan 2007 02:26:11 -0800
Links: << >>  << T >>  << A >>
> As I said, I need to have a 1 line delay, because of sync with the DVI
> timing, both input and output of my module must be in sync with it.
> (well, withing a few clock cycles of pipeline ...)

Well in this case, apart from crazy adressing schemes which may cost
you a lot in control and headache, I see no simple solution. If you're
really tight on block rams, it won't cost you much to duplicate the DVI
engine (if DVI is generated on-board) or simply delay the DVI control
by half a line with CLB shift-registers (if generated externally).
Can't you really do this ?

> So with this scheme (two FIFO), the FIFO storing the the first half of
> line would need to be bigger.
> At the end of the line, both fifo would be full with the pixel of that
> line. Then during the first half of the next line, at each clock cycle,
> I would be reading 1 pixel, and pushing 2 pixels. And that for half a
> line, so the first fifo would need to be 3/4 of a line and the second
> one would need to be 1/2 a line. So I'm over my "quota" of 1 line of
> video storage.

Totally agreed.

JB


Article: 114653
Subject: Clock constraints
From: "skyworld" <chenyong20000@gmail.com>
Date: 22 Jan 2007 02:43:49 -0800
Links: << >>  << T >>  << A >>
Hi,
I will input a differential clock to DCM, how should I set contraints?
Should I set constraint on IBUFGDS input or should I set constraint on
its output? And should I set constraints on DCM outputs? Thanks.


Article: 114654
Subject: Re: "Divide" a video line in two stripe
From: "Sylvain Munaut <SomeOne@SomeDomain.com>" <246tnt@gmail.com>
Date: 22 Jan 2007 02:44:00 -0800
Links: << >>  << T >>  << A >>

jbnote wrote:
> > As I said, I need to have a 1 line delay, because of sync with the DVI
> > timing, both input and output of my module must be in sync with it.
> > (well, withing a few clock cycles of pipeline ...)
>
> Well in this case, apart from crazy adressing schemes which may cost
> you a lot in control and headache, I see no simple solution. If you're
> really tight on block rams, it won't cost you much to duplicate the DVI
> engine (if DVI is generated on-board) or simply delay the DVI control
> by half a line with CLB shift-registers (if generated externally).
> Can't you really do this ?

Duplicating the DVI isn't really an option. It's not that small because
it's
entirely programmable dynamically.

And I liked the line delay because I already have other blocks in
the pixel processing path that have a line delay, so I already
have the logic to handle these.

And the half line delay need to be programmable as my resolution might
max out at 3840 but it's in fact programmable dynamically ...


I was kindof looking for some addressing trick that would have allowed
me to do this without too much logic and not more BRAMs ...
But I've been searching and so far didn't find anything ...


Article: 114655
Subject: Re: digilent nexys vga glitches
From: "RedskullDC" <RedskullDC@SPAM.yahoo.com.au>
Date: Mon, 22 Jan 2007 23:56:23 +1100
Links: << >>  << T >>  << A >>
Hi Corer,

"Corer" <corer@somewhere.net> wrote in message 
news:GlDsh.2913$O02.2241@newssvr11.news.prodigy.net...
> Newbie problem:
> I get some nasty horizontal jitter on vga display
> controlled by a vga controller (see below) running
> on a digilent nexys board. It looks like all scan lines
> jitter relative to each other (couple of pixels left/right).
> The problem is worse on the first 1/16th of the screen
> and it is getting better below (still jitters on the bottom
> though).
>
> Looking at the hsyncs via an oscilloscope shows that
> the pulses do actually slide left and right like crazy and
> are really unstable (10-20ns jitter).
>
> I tried to look at the output of a production vga adapter
> and it looks more stable (do not jitter as much) and the
> edges of the pulses are much more "square" (raise time is
> much smaller). Another difference is with the voltage -
> nexys uses 3.3v and it looks like the vga adapter I tried
> has 5v output.
>
> I looked all over the internet and it doesn't seem like
> anybody else has this problem. Have anybody tried
> to get a nice and stable picture via nexys vga?
> What am I doing wrong? Is it supposed to be that
> "imperfect"? How do I fix it?

No probs using the Nexys this end. I have the VGA adapter card aswell.
Tried it with 640x480 and 800x600, 60Hz.

Couldn't get 1024x768 working properly, but that will be a job
for a rainy weekend.

I was using a 25MHz pixel clock though, as in the "squares"
example from:
http://www.derepas.com/fabrice/hard/

25 or 50MHz inputs on MCLK instead of the 100MHz you are
using may be more forgiving.

Cheers,
Red




Article: 114656
Subject: Re: what happened to modular design in ISE9
From: "Dolphin" <Karel.Deprez@gemidis.be>
Date: 22 Jan 2007 05:46:51 -0800
Links: << >>  << T >>  << A >>
Hello,

Didn't they replace that with PlanAhead ?

best regards,
Karel

backhus schreef:
> Hi,
> while Iwere reading some chapters of the new ISE9 Development System
> Reference guide I happened to notice that the chapters about Incremental
> Design and Modolar Design are gone.
>
> What happened? Have these approaches been dropped? If so, I would like
> to know the reasons. Is there some new (better) approach? Or have these
> chapters just moved to some yet unpublished ISE9 document? (I know they
> are still available in the ISE8 doc files.)
> 
> Best regards
>    Eilert


Article: 114657
Subject: Re: Source Synchronous LVDS Design - Phase Shift in the Timing Analysis?
From: "Christian Wiesner" <cw@midimonster.de>
Date: 22 Jan 2007 06:06:44 -0800
Links: << >>  << T >>  << A >>
> 1.875ns, but this is not reflected in the constraints. Am I missing
> something?

Indeed I was missing something:

The param "IFD_DELAY_VALUE => "AUTO" from the IBUFDS of the DATA-lines
was set to AUTO. I do not know what the ISE Webpack did there, I got an
delay from nearly 6ns while the DATA went from the PIN thru the IBUFDS
to the input-FF. I assume, it controls the delay through the PAD. So I
got horrible setup-times.

When I changed this value back to "0", my constraints were met. I used
the "Language Templates" provided in the Webpack.

But this doesn't solve my issue concerning the Phase of the DCM. If I
change the phase, nothing changes in the setup-time. Only the
"datasheet"-section in the timingreport reflects the phasechange
correct.

regards,
Christian


Article: 114658
Subject: Re: Phasse Detector
From: "Symon" <symon_brewer@hotmail.com>
Date: Mon, 22 Jan 2007 14:14:43 -0000
Links: << >>  << T >>  << A >>

"Peter Alfke" <peter@xilinx.com> wrote in message 
news:1169245545.109593.309790@l53g2000cwa.googlegroups.com...
> The classical 30+-year old phase/frequency comparator is the Motorola
> MC4044.
> (I copied its structure into my Xilinx app note XAPP028)
> Just google both these circuits...
> Peter Alfke
>

Here's a repost from 2003! BTW, since then I now think the equivalent 
circuit made from two FFs is much better.

Hi,
   A small note of caution when using Peter's XAPP028 in Virtex II. As
well as constraining the logic to the CLBs shown in the app note, make
sure you specify a MAXSKEW attribute on the reference signal and
feedback signal to the circuit. I use 100ps. Without this the circuit
can occasionally malfunction depending on the place and route. (These
are the signals called 'from VCO divided by N' and 'from reference
frequency'.)
   There was no problem when this circuit was used on older FPGAs
where the routing to the F and G lookup tables in a single CLB was
guaranteed to have low skew. In Virtex II this is no longer the case
and a single signal that goes to both the F and G inputs of a CLB can
have significant skew if not constrained. This can cause the circuit
of XAPP28 to misbehave.
   Of course it's not your fault Peter that those guys changed the
routing from the original 3000 (I guess) design! Thanks for a good APP
note I've used many times, maybe it needs a small update!
             HTH, Syms.
p.s. I'm not sure which Xilinx families need the MAXSKEW, I use it
always because it can't hurt. Also, make sure the signals don't
connect anywhere else, or the MAXSKEW will fail. Replicate them if
necessary. 



Article: 114659
Subject: Xilinx doing a re-entry in non-volatile FPGA arena!!!
From: "Antti" <Antti.Lukats@xilant.com>
Date: 22 Jan 2007 07:07:38 -0800
Links: << >>  << T >>  << A >>
With Spartan-3AN is Xilinx making its entry in the non-volatile FPGA
arena.

I am glad that this can now be discussed in open, as WebPack 9.1
includes already support for S3-AN.
So my speculations, about "Why S3-A if its not volatile" was justified,
with the only difference that S3-A has 2 derivates, with and without
integrated non-volatile storage.

Antti


Article: 114660
Subject: Scrambling for Lattice SC
From: "ALuPin@web.de" <ALuPin@web.de>
Date: 22 Jan 2007 08:08:52 -0800
Links: << >>  << T >>  << A >>
Hi newsgroup,

is it possible to design some scrambling mechanism for Lattice SC FPGAs
with some additional CPLD/FPGA ?
Unfortunately there is no integrated circuit included yet to protect
the bitstream.

Thank you for your opinions.

Rgds
Andre


Article: 114661
Subject: Re: what happened to modular design in ISE9
From: "Tim Verstraete" <tim.verstraete@barco.com>
Date: 22 Jan 2007 08:14:55 -0800
Links: << >>  << T >>  << A >>

i think they were replaced with the partitions flow (ISE8.2i)? or am i
wrong?

backhus schreef:
> Hi,
> while Iwere reading some chapters of the new ISE9 Development System
> Reference guide I happened to notice that the chapters about Incremental
> Design and Modolar Design are gone.
>
> What happened? Have these approaches been dropped? If so, I would like
> to know the reasons. Is there some new (better) approach? Or have these
> chapters just moved to some yet unpublished ISE9 document? (I know they
> are still available in the ISE8 doc files.)
> 
> Best regards
>    Eilert


Article: 114662
Subject: Re: Xilinx doing a re-entry in non-volatile FPGA arena!!!
From: "jetq88" <jetq5188@gmail.com>
Date: 22 Jan 2007 08:37:35 -0800
Links: << >>  << T >>  << A >>
you mean there is no need for PROM? it's sure convienient for customer.
do they use Flash or EEprom ?

jet

Antti wrote:
> With Spartan-3AN is Xilinx making its entry in the non-volatile FPGA
> arena.
>
> I am glad that this can now be discussed in open, as WebPack 9.1
> includes already support for S3-AN.
> So my speculations, about "Why S3-A if its not volatile" was justified,
> with the only difference that S3-A has 2 derivates, with and without
> integrated non-volatile storage.
> 
> Antti


Article: 114663
Subject: Re: Xilinx doing a re-entry in non-volatile FPGA arena!!!
From: nico@puntnl.niks (Nico Coesel)
Date: Mon, 22 Jan 2007 16:40:06 GMT
Links: << >>  << T >>  << A >>
"jetq88" <jetq5188@gmail.com> wrote:

>you mean there is no need for PROM? it's sure convienient for customer.
>do they use Flash or EEprom ?

More important: does it have a proper content theft protection system?

>jet
>
>Antti wrote:
>> With Spartan-3AN is Xilinx making its entry in the non-volatile FPGA
>> arena.
>>
>> I am glad that this can now be discussed in open, as WebPack 9.1
>> includes already support for S3-AN.
>> So my speculations, about "Why S3-A if its not volatile" was justified,
>> with the only difference that S3-A has 2 derivates, with and without
>> integrated non-volatile storage.
>> 
>> Antti
>

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 114664
Subject: Re: Xilinx doing a re-entry in non-volatile FPGA arena!!!
From: "Antti" <Antti.Lukats@xilant.com>
Date: 22 Jan 2007 08:42:10 -0800
Links: << >>  << T >>  << A >>
jetq88 schrieb:

> you mean there is no need for PROM? it's sure convienient for customer.
> do they use Flash or EEprom ?
>
> jet
>
> Antti wrote:
> > With Spartan-3AN is Xilinx making its entry in the non-volatile FPGA
> > arena.
> >
> > I am glad that this can now be discussed in open, as WebPack 9.1
> > includes already support for S3-AN.
> > So my speculations, about "Why S3-A if its not volatile" was justified,
> > with the only difference that S3-A has 2 derivates, with and without
> > integrated non-volatile storage.
> >
> > Antti
it looks like serial flash to the user logic, and it can be accessed
after configuration.

Antti


Article: 114665
Subject: Re: Xilinx doing a re-entry in non-volatile FPGA arena!!!
From: "Benjamin Todd" <benjamin.toddREMOVEALLCAPITALS@cernREMOVEALLCAPITALS.ch>
Date: Mon, 22 Jan 2007 17:53:47 +0100
Links: << >>  << T >>  << A >>
Sounds interesting.. Antti, have you any idea of the size of the N.V. 
memory, and whether (as jet wrote) it can be used to store a configuration? 
I haven't gotten around to installing 9.1 yet, maybe i'll make it more of a 
priority. Ben

"Antti" <Antti.Lukats@xilant.com> wrote in message 
news:1169484130.644970.290580@38g2000cwa.googlegroups.com...
> jetq88 schrieb:
>
>> you mean there is no need for PROM? it's sure convienient for customer.
>> do they use Flash or EEprom ?
>>
>> jet
>>
>> Antti wrote:
>> > With Spartan-3AN is Xilinx making its entry in the non-volatile FPGA
>> > arena.
>> >
>> > I am glad that this can now be discussed in open, as WebPack 9.1
>> > includes already support for S3-AN.
>> > So my speculations, about "Why S3-A if its not volatile" was justified,
>> > with the only difference that S3-A has 2 derivates, with and without
>> > integrated non-volatile storage.
>> >
>> > Antti
> it looks like serial flash to the user logic, and it can be accessed
> after configuration.
>
> Antti
> 



Article: 114666
Subject: Re: Xilinx doing a re-entry in non-volatile FPGA arena!!!
From: "Antti" <Antti.Lukats@xilant.com>
Date: 22 Jan 2007 09:02:47 -0800
Links: << >>  << T >>  << A >>
Nico Coesel schrieb:

> "jetq88" <jetq5188@gmail.com> wrote:
>
> >you mean there is no need for PROM? it's sure convienient for customer.
> >do they use Flash or EEprom ?
>
> More important: does it have a proper content theft protection system?
>
> >jet
> >
> >Antti wrote:
> >> With Spartan-3AN is Xilinx making its entry in the non-volatile FPGA
> >> arena.
> >>
> >> I am glad that this can now be discussed in open, as WebPack 9.1
> >> includes already support for S3-AN.
> >> So my speculations, about "Why S3-A if its not volatile" was justified,
> >> with the only difference that S3-A has 2 derivates, with and without
> >> integrated non-volatile storage.
> >>
> >> Antti
> >
>
> --
> Reply to nico@nctdevpuntnl (punt=.)
> Bedrijven en winkels vindt U op www.adresboekje.nl

S-3A (and AN) have at least the DNA (factory serial number), so this
could potentially be used for design theft protection. I dont know
about other measures that may be present additionally.

Antti


Article: 114667
Subject: Re: Xilinx doing a re-entry in non-volatile FPGA arena!!!
From: pbgbbrsh@ludd.invalid
Date: 22 Jan 2007 17:04:22 GMT
Links: << >>  << T >>  << A >>
Antti <Antti.Lukats@xilant.com> wrote:
>With Spartan-3AN is Xilinx making its entry in the non-volatile FPGA
>arena.

>I am glad that this can now be discussed in open, as WebPack 9.1
>includes already support for S3-AN.
>So my speculations, about "Why S3-A if its not volatile" was justified,
>with the only difference that S3-A has 2 derivates, with and without
>integrated non-volatile storage.

Any price indication for the XC3S50A-TQ144 part ..? and the rest? RoHS?

Only Avnet, NuHorizons listed as suppliers..

Will there be any more than 50k chips in non-bga package?


Article: 114668
Subject: Re: Xilinx doing a re-entry in non-volatile FPGA arena!!!
From: Austin Lesea <austin@xilinx.com>
Date: Mon, 22 Jan 2007 09:06:56 -0800
Links: << >>  << T >>  << A >>
Antti,

See:

http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=24332

Answer Record 24332.

Sorry to keep everyone guessing, but we will announce when we are ready.

Austin

Article: 114669
Subject: Re: Xilinx doing a re-entry in non-volatile FPGA arena!!!
From: "Antti" <Antti.Lukats@xilant.com>
Date: 22 Jan 2007 09:49:50 -0800
Links: << >>  << T >>  << A >>
Austin Lesea schrieb:
> Antti,
>
> See:
>
> http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=24332
>
> Answer Record 24332.
>
> Sorry to keep everyone guessing, but we will announce when we are ready.
>
> Austin

Hi Austin,

I hope I havent said anything too much, I felt it is OK to let the cat
out of sack, as the WP9.1 includes the S3-AN support files. And sure I
know that for the actual release and full docs there is no public
discussion until full release.

BTW the AR about ISE 9.1 and S3AN has date: 12/05/06 08:00:36 !?
Kind of weird that this AR was filed before ISE 9.1 availability.

Antti


Article: 114670
Subject: Re: Correction for hwicap_v1_00_a code
From: Neil Steiner <neil.steiner@vt.edu>
Date: Mon, 22 Jan 2007 13:00:48 -0500
Links: << >>  << T >>  << A >>
Hi John,

>> I was writing a linux kernel driver for the icap, 
> 
> You mean like this one:
> 
> http://www.itee.uq.edu.au/~listarch/partial-reconfig/archive/2006/04/msg00009.html 
> 
> ?

Yes, it is similar to yours, and I did download your xilinx_hwicap 
before starting to work on mine.  (And I certainly appreciate you making 
your code available.)  I ended up writing mine from scratch though 
because I wanted to get gain a better understanding of linux drivers, 
but more importantly because I wanted to be able to talk to the device 
as /dev/icap from Java code (without JNI) or from a shell.  I also 
wanted to parse the bitstream header so that I could accept any normally 
generated bitstream, and I believe your code assumes that there is no 
header.

> I think I came across similar issues - with HWICAP you must always write 
> a full frame at a time which means buffering in the driver in case the 
> user does something like multiple byte writes (e.g. from "cat") instead 
> of a nice big block write.

I did pick up that same impression from someone inside Xilinx, but with 
the correction that I mentioned, I've had no problem just writing the 
data as it comes in.  As you're suggesting, "as it comes in" from 
something like cat or cp or a Java write function, is completely 
arbitrary, and unlikely even to be word aligned.  (Admittedly, I do have 
to pack the bytes into words, much like you do.)  Perhaps I'm just 
lucking out, but my icap driver routinely writes data that is decidedly 
not split along frame boundaries, as the driver neither knows nor cares 
where those boundaries fall.

Based on what I know of your driver, the correction that I mentioned 
should work just as well for you as it did for me, and you might find 
that it frees you from having to stick to frame boundaries.  We can 
compare code offline if need be.

Neil

Article: 114671
Subject: Xilinx ISE 8.2
From: "bgshea" <bgshea@gmail.com>
Date: 22 Jan 2007 10:17:29 -0800
Links: << >>  << T >>  << A >>
I'm looking for POSITIVE feedback on Xilinx ISE. Yes i realize it has
it problems, but It's free. So, I've been looking round the WWW to find
some tips on what type of system (Windows, Linux, Intel x86 or EM86_64,
AMD, etc) that might result in better software preformace.

Also, considering the effects of the Java RTE.

I would like to post these suggestions to a page on my site, but if
this turns in to a flaming war, i will cease and go elsewhere.

So, here is what I have, and my problems:

I have a Windows XP based system with Xilinx 8.2.03 and Chip Scope Pro.
AMD Athlon 64 3000+
1GB DDR RAM

Here are my issues:

During the hardware validation process, i tend to make many small
changes to several projects (i have 4 FPGAs in my system on seperate
cards all being developed in parallel), esp to CSP which requires many
rebuilds and downloads. Since I'm working with Spartan 2 I cannot take
advantage of Partitioned designs.  After about 10 or so builds and
downloads my physical ram usage is 1.5GB and my system is swappping
consistanly. Reviewing the windows resource usage, it shows only about
150MB for _PN.exe, however, closing the ISE will free up nearly 1GB of
ram.

So, is this a Java issue, should I upgrade my JRE, or does ISE use it's
own JRE?

Is it a System issue, should I switch to a Linux based environment? or
Drop back to an older version of Windows such as w2k.

Could it be a design flaw in my Design. I use a TLD with only IO Logic
and Global Clock buffers, all modules/sub modules contain related
functional logic. TLD only provides wired interconnect between modules,
no tri-state buses. Modules register inputs and outputs on clock edges.

I haved contacted Xilinx on this matter, and will leave it at that to
stay imparital.

Thanks for any feedback.

Brian


Article: 114672
Subject: Re: Xilinx doing a re-entry in non-volatile FPGA arena!!!
From: Austin Lesea <austin@xilinx.com>
Date: Mon, 22 Jan 2007 10:28:09 -0800
Links: << >>  << T >>  << A >>
Antti,

No problem.  We have to release our software on a regular schedule, so
there is no holding it back.

I would caution that whatever is revealed in the software may be updated
or changed in the future, so the recommendation to work with our FAEs
(if you really want to use a product before its release) is still valid.

Austin


Article: 114673
Subject: Re: Considerations for FPGA Based Acceleration in Bio medical simulations/computational biology
From: pbgbbrsh@ludd.invalid
Date: 22 Jan 2007 18:39:17 GMT
Links: << >>  << T >>  << A >>
>(1)  Many of the end-customers now use laptops as their only computers,
>sometimes with a docking station and/or external keyboard and monitor
>when they're at their desks. How would a endcustomer implement such a
>hardware solution? Would it come as a plug-in card for a card slot
>(unusable on a laptop), or in some format that would enable using it on
>a laptop? How about a standalone box?

You could use PCI-express x1 on newer laptops which transfers 2.5 Gbit/s.
Other than that there's ethernet, usb2.
(with ethernet you could share the unit easy between hosts)

>(2) Assuming one is able to connect the HW implementation to a laptop,
>how would the end customer feed the input files. Note that in some
>apps, the input file is ASCII text, while in other apps, it may be
>binary files in a proprietary format. How does the output of the
>simulation be collected? Wd it be redirected to an ASCII text file?

It's a matter of converting data between your application and the protocol
you define in the fpga.

>(3)   What happens when the algorithm needs to be updated? Is there a
>way to "update" the hardware (such as an FPGA), or does is it mean the
>hardware becomes obsolete and must be replace (if so, at what kind of
>cost to an end user)?

It can be a simple matter of "recompiling" to use C/C++ language terms.
Then you use the same communication channel as for sending data to load
the new algorithm(s).

>(4)   Hardware/Software Partitioning: Can various "core" functions be
>programmed into the hardware while still allowing other functions to be
>in software in order to provide flexibility in the mathematical models?
>If so, is the potential speed advantage still high?

Partitioning is balance of communication demands and speed benefits.
Other than than partitioning can be done in any manner. There's also the
option of reprogramming the fpga "in-flight" to accelerate different
algorithms as needed.

>(5) Can you shed some light on how  one can translate existing code
>from C/C++ to a HW platform? What tools would be used, how would the
>design be verified, and how long does it take to get a working demo
>version?

Maybe SystemC could be of use. It proberbly needs to be done at the 
algorithmic level. On those parts (functions) that will benefit from it.
The main issue is wheather the algorithm & data can be parallised and
pipelined in such way it will actually be faster.
A function call would essentially take parameters, send them to fpga,
await answer from fpga, return data.

>(6) What about if the existing code is in a proprietary language, other
>than C/C++? Is it possible to translate into a HW mapping in that case?

Can be done.

>(7) Finally, to get a demo/working prototype, what do you recommend,
>FPGA, or ASIC or something in between and why? If you had to take a
>stab at guessing the cost for developing such a prototype, what would
>it be? Assume about 100,000 lines of existing code in C/C++.

FPGA in this case because requirements are not 100% clear. FPGA allows easy
changes compared to ASIC. FPGA can be reused in way ASIC can't aswell.
ASIC can be used in later stage when algorithms are more settled for
massive computeing cluster or similar.

I think the cost is quite dependent on the particular setup..


Article: 114674
Subject: Re: Ethernet Interface
From: "davide" <davide@xilinx.com>
Date: Mon, 22 Jan 2007 10:48:32 -0800
Links: << >>  << T >>  << A >>
Aswin,

Lets take the Virtex-5 LX50T as an example.  You could utilize a soft 
processor core(MicroBlaze) within the fabric for your packet processing and 
interface that to the embedded EMAC.  Take a look at XAPP-443 
(http://www.xilinx.com/bvdocs/appnotes/xapp443.pdf).  This provides a good 
example of how a soft processor can be designed to manage the EMAC 
configuration registers, generate frames, edit frames, etc and provides a 
seemless interface to the EMAC.

In terms of efficiency (speed), it is a matter of knowing what your 
throughput needs are for the uP and simulating.  In terms of efficiency for 
additional hardware requirements and board area, I think the FPGA is more 
practical.

-David

"Surya" <aswingopalan@gmail.com> wrote in message 
news:1169186710.800606.31640@v45g2000cwv.googlegroups.com...
> Dear David,
>
>    Thank you for your link. It was good. I was aware of the EMACs
> present in the Virtex 4 and 5. But i was wondering whether it would be
> efficient to write the protocol handler to (removing and addition of
> header and footer in simple terms) in the FPGA directly or in the PPC.
> If it is in PPC i would not be able to use Virtex 5 and hence the EMAC.
>
>
>   Kindly advise.
>
>
> Aswin
>
> davide wrote:
>> Hi Surya,
>>
>> Are you aware that the Xilinx Virtex-4 and Virtex-5 FPGA have an embedded
>> EMAC block?  Here is a great article to serve as a starting point:
>> http://www.xilinx.com/publications/xcellonline/xcell_59/xc_pdf/p054-056_59-McKay.pdf
>>
>> -David
>>
>> "Surya" <aswingopalan@gmail.com> wrote in message
>> news:1169033036.685087.68370@51g2000cwl.googlegroups.com...
>> >
>> > Is it possible to interface the Ethernet directly to the FPGA instead
>> > of the doing it through the Power PC processor or any other Processor?
>> > If yes, kindly throw some light on the same.
>> >
>> > thanks in advance.
>> >
> 





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