Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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 JBArticle: 114651
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. SylvainArticle: 114652
> 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. JBArticle: 114653
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
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
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, RedArticle: 114656
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 > EilertArticle: 114657
> 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, ChristianArticle: 114658
"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: 114659With 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. AnttiArticle: 114660
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 AndreArticle: 114661
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 > EilertArticle: 114662
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. > > AnttiArticle: 114663
"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.nlArticle: 114664
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. AnttiArticle: 114665
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
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. AnttiArticle: 114667
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
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. AustinArticle: 114669
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. AnttiArticle: 114670
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. NeilArticle: 114671
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. BrianArticle: 114672
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. AustinArticle: 114673
>(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
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:
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