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
On Sat, 12 Dec 2009 23:23:22 -0800 (PST), Eric Smith <spacewar@gmail.com> wrote: On Sat, 12 Dec 2009 23:23:22 -0800 (PST), in comp.arch.fpga you wrote: >> The data2mem tool doesn't require you to know the physical location of >> a particular BlockRAM, it just needs to know what the name is like a >> UCF file does.http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/data2... > >Thanks! I'm still confused since that manual says (page 28) "The BMM >file <i>must</i> have LOC or PLACED constraints for each block RAM. >These constraints can be added manually, but they are most often >obtained as an annotated BMM file from Bitgen. For information, see >Using Integrated ISE(R) Design Suite Implementation Tools." The information you need is not where you need it, but probably exists somewhere else. Dim and distant memory leads me to: Webcase 720619 may be relevant (though it was from the ISE7.1 and 9.1 days) https://xapps2.xilinx.com/eSupport/eSupportJSP/CaseShow.jsp?id_number=720619 If you can't see it without too many registration steps, I'll post some excerpts from it here. Two quotes from it: ----------------------------------------------------------------------------------------------------------------------------- Problem 1: XILINX TOOL DEFECT When NGDbuild fails to process a BMM file, it does not issue a Warning or an Error as it should; just a note in the .bld log file. This makes finding problems harder. (May have been fixed since 7.1; I haven't checked with Webpack 9.2) ----------------------------------------------------------------------------------------------------------------------------- What DID help were AR#23179 and AR#24296 which explained how the "magic" worked. Remember: The problem manifested as PAR failing to generate a _bd.bmm file from a flow which previously worked. Yet none of the documentation (prior to the above AR#s) explained how it did this, to help pinpoint the problem. So it was unclear what communicated the BMM filename or the need to annotate into PAR; therefore where to look to solve the problem. I had to find the above AR#s to understand that the BMM filename is buried in the .ncd file as a result of NGDbuild parsing it correctly; since it was missing in the XDL file, that pointed back to NGDbuild (where I found the failure as an obscure note in the BLD file). ----------------------------------------------------------------------------------------------------------------------------- So http://www.xilinx.com/support/answers/23179.htm and http://www.xilinx.com/support/answers/24269.htm may be helpful. There was a Change Request (CR #457644) to address issues with the documentation; I don't know what happens to CRs but the documentation may still be incomplete. If you find this to be so, it is worth pursuing further with Xilinx Support. But essentially, you need to supply a BMM file (xxx.bmm) with BRAM names (and no LOC constraints) to ... actually "Translate" aka NGDbuild - AND CHECK THE BUILD REPORT .bld to see it was handled correctly... (This .bmm file is usually generated by EDK, but you can hand-edit it, e.g. to alter hierarchical names if you use an EDK generated design as a component in a larger design) Then the .bmm information disappears into the tool flow, only to re-emerge at Bitgen, (I believe, though I said PAR in my quote above) which takes the same BMM file and annotates it with placement, saving as xxx_bd.bmm. Hope this helps. - BrianArticle: 144526
Jonathan Bromley wrote: > On Sat, 12 Dec 2009 11:26:54 -0800 (PST), Peter Alfke > <alfke@sbcglobal.net> wrote: > >> In short: >> changing a SINGLE lut input will NEVER generate a glitch. > > Nice to know, and - thinking about the likely structures > for the guts of a LUT - perfectly reasonable. Thanks. > > However.... can all other manufacturers of LUT-based > FPGAs make the same promise? Again, *probably* yes; > but would you bet your life/reputation/fortune on it? Hi Jonathan, Think about it this way. If you deliberately wanted to make the output of a 2^N to 1 mux glitch if only one select input changes, how would you do it? Cheers, Syms.Article: 144527
On Dec 13, 6:10=A0am, Symon <symon_bre...@hotmail.com> wrote: > Jonathan Bromley wrote: > > On Sat, 12 Dec 2009 11:26:54 -0800 (PST), Peter Alfke > > <al...@sbcglobal.net> wrote: > > >> In short: > >> changing a SINGLE lut input will NEVER generate a glitch. > > > Nice to know, and - thinking about the likely structures > > for the guts of a LUT - perfectly reasonable. =A0Thanks. > > > However.... can all other manufacturers of LUT-based > > FPGAs make the same promise? =A0Again, *probably* yes; > > but would you bet your life/reputation/fortune on it? > > Hi Jonathan, > Think about it this way. If you deliberately wanted to make the output > of a 2^N to 1 mux glitch if only one select input changes, how would you > do it? > Cheers, Syms. It can be done: Suppose both data inputs are High, while you change the select input from High to Low. Suppose the deselect path is faster than the select path, then you will see a Low glitch on the output. The OP's concern is legitimate, but I had investigated and found out and documented several times: A mux implemented in a single Xilinx LUT does not have this problem, since it uses pass transistors, and the internal capacitance "bridges" the change-over. I would assume that the other big FPGA company does it the same way. They are just not as forthcoming with helpful information. Peter AlfkeArticle: 144528
Symon <symon_brewer@hotmail.com> wrote: > Think about it this way. If you deliberately wanted to make > the output of a 2^N to 1 mux glitch if only one select input > changes, how would you do it? If the transistors selecting one input turn off before the ones selecting the second input (of a 2 to 1) turn on then the output floats. Most likely there is enough capacitance to keep the old value though. If the second one turns on faster, and the output value is changing, then you get a lot of current for (hopefully) a very short time. -- glenArticle: 144529
> >wire a = b ? 1 : count[0]; > And this differs from wire a = b || count[0]; How? ----------------------------------------- However.... can all other manufacturers of LUT-based FPGAs make the same promise? Again, *probably* yes; but would you bet your life/reputation/fortune on it? ----------------------------------------- Thats the big problem with design for reuse. You have to design for the lowest common denominator. I don't care what your new fpga family can do unless it does it the same as everyone else.Article: 144530
>Thanks again chaps I'll keep you all updated so you can have a good >chuckle at watching a noob stratch his head and do lots of stupid >things :)!!!!! > Sorry for reviving an old thread, but I'm curious about how your project went. I need to start getting ready for my own senior design project (May 2011), and I'm thinking of something similar with the DS but not exactly the same. My goal would be to get an analog RGB/YPbPr output at 480i/p. Although getting the output is quite the task, my project's main focus would be various selectable screen output modes. For example: Mode A) Top Screen only, 256 x 192 centered with black borders all around Mode B) Bottom Screen only, 256 x 192 centered with black borders all around Mode C) Top Screen only, 256 x 192 resized to 640 x 480 Mode D) Top screen above Bottom screen, no gap between screens Mode E) Top screen above Bottom screen, 64-line gap filled with interpolated data from both screens and/or motion predicted pixels and so forth.... This brings me to a few questions directed at anyone willing to answer. With all the extra DSP aspects of my desired features, would the Spartan-3 still be a good candidate for this project? Or will I need something more powerful? I would like to be taking FFTs to help with the video scaling, so I would prefer something capable of that. But, I can avoid the frequency domain altogether if the price difference for that capability is too large. Also, I would probably need to buffer more than one frame for the gap interpolation, so wouldn't I need more RAM? If I do need something more powerful, then what is recommended? I was actually looking at these two kits before I found this thread: http://www.xilinx.com/products/devkits/HW-SPAR3A-SK-UNI-G.htm http://www.xilinx.com/products/devkits/HW-SD1800A-DSP-SB-UNI-G.htm Also, to add: I've never used FPGAs before, but just like the author (of this thread) I'm willing to put in most of my free time since I'm not able to take the FPGA course at my school until Spring 2011 (which is too late). A major goal of this project is to learn about FPGAs. Any tidbits of help on this would be greatly appreciated. Thank you.Article: 144531
jt_eaton <z3qmtr45@gmail.com> wrote: >>wire a = b ? 1 : count[0]; > And this differs from > wire a = b || count[0]; > How? It doesn't, but it isn't completely obvious, at least not in an FPGA, what actually happens. -- glenArticle: 144532
On Sun, 13 Dec 2009 14:10:35 +0000, Symon <symon_brewer@hotmail.com> wrote: >Jonathan Bromley wrote: >> On Sat, 12 Dec 2009 11:26:54 -0800 (PST), Peter Alfke >> <alfke@sbcglobal.net> wrote: >> >>> In short: >>> changing a SINGLE lut input will NEVER generate a glitch. >> >> Nice to know, and - thinking about the likely structures >> for the guts of a LUT - perfectly reasonable. Thanks. >> >> However.... can all other manufacturers of LUT-based >> FPGAs make the same promise? Again, *probably* yes; >> but would you bet your life/reputation/fortune on it? > >Hi Jonathan, >Think about it this way. If you deliberately wanted to make the output >of a 2^N to 1 mux glitch if only one select input changes, how would you >do it? If your implementation comes out to be break before make, it's quite easy to do. Assume the following implementation: wire o = (!s & a) | (s & b). If the inverter is slow enough, both and gates will have their select inputs low when s changes high to low. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 144533
On Dec 13, 12:42=A0pm, Peter Alfke <al...@sbcglobal.net> wrote: > The OP's concern is legitimate, But, as is usually the case with these types of queries, it's indicative of either a flawed design approach or choosing to make your own life more difficult. The OP concern over performance that prompted the query was after deliberately choosing to use a much lower performance mode of operation than what was available...if you choose to use a screwdriver to pound in nails when a hammer is available, then why concern yourself with the performance differences between between Phillips, Torx, or flat blade? > > I would assume that the other big FPGA company does it the same way. > They are just not as forthcoming with helpful information. I seem to recall that company A has documented this as well. I seem to recall running across it...but doubt that I would ever have a need to make use of that little tidbit of info. Kevin JenningsArticle: 144534
>> The OP's concern is legitimate, > >But, as is usually the case with these types of queries, it's >indicative of either a flawed design approach or choosing to make your >own life more difficult. The OP concern over performance that >prompted the query was after deliberately choosing to use a much lower >performance mode of operation than what was available...if you choose >to use a screwdriver to pound in nails when a hammer is available, >then why concern yourself with the performance differences between >between Phillips, Torx, or flat blade? > >> >> I would assume that the other big FPGA company does it the same way. >> They are just not as forthcoming with helpful information. > >I seem to recall that company A has documented this as well. I seem >to recall running across it...but doubt that I would ever have a need >to make use of that little tidbit of info. > >Kevin Jennings I would have to disagree with you here. There are two modes of operation for this chip: a) Synchronous: One channel at ~25MB/s. b) Asynchronous: Two channels of max ~10MB/s. This means that the two modes are somewhat similar in terms of performance, if one can achieve close to this maximum of 10MB/s. My application has a streaming part, and a control part. Splitting the two makes software and hardware developpement and architecture much easier. The 'control channel' just works all the time, gives feedback about the status of the streaming FIFO etc...while the 'streaming channel' doesn't have to deal with demuxing commands out of the stream... This sounds like a reasonnable decision, if I can live with the asynchronous performance. In fact, I can, given I stay close to the 10MB/s. I'm trying to find a circuit that will allow me to stay close to this, without running at 500GHz, since I'm in a Spartan 3. Maybe 50M or 100M would be good. Even with the good news that the mux will not glitch, I failed to find a circuit that would work... If anybody has an idea, please let me know... Diego --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 144535
KJ <kkjennings@sbcglobal.net> wrote: (Peter wrote) >> The OP's concern is legitimate, > But, as is usually the case with these types of queries, it's > indicative of either a flawed design approach or choosing to make your > own life more difficult. The OP concern over performance that > prompted the query was after deliberately choosing to use a much lower > performance mode of operation than what was available...if you choose > to use a screwdriver to pound in nails when a hammer is available, > then why concern yourself with the performance differences between > between Phillips, Torx, or flat blade? We don't have all the details of the OP's project. It might the data source is asynchronous, and that asynchronous FIFO is the best choice. -- glenArticle: 144536
I can't even get this simple code to work in the inserter module two_input_xor ( input wire in1, input wire in2, output wire out ); assign out =3D in1 ^ in2; endmodule On Dec 9, 6:48=A0am, Martin Thompson <martin.j.thomp...@trw.com> wrote: > Andy Peters <goo...@latke.net> writes: > > On Dec 7, 6:26=A0am, Martin Thompson <martin.j.thomp...@trw.com> wrote: > >> laserbeak43 <laserbea...@gmail.com> writes: > >> > Hello, > >> > =A0 =A0 I've just been shown Signaltap, A feature in Quartus Webpack > >> > Edition. Does the Webpack Edition of ISE have this feature? WOW this > >> > alone can convince me to use Altera products. > > >> Chipscope is the Xilinx equivalent - it's not in webpack (personally, = I > >> think that's a mistake on Xilinx's part) > > >> But comparing it to Signaltap may (IMHO) leave you underwhelmed... it'= s > >> very disjointed and unintegrated in comparison. =A0I'm still using FPG= A > >> editor to change which signals to monitor, then having to update the > >> viewer by hand! V. tedious. > > > Really? What version of ChipScope are you using? > > 10.1.3 > > > > > Use the ChipScope Core Inserter. > > Indeed, I could (and have in the past), but > > a) I'm using the EDK variety of core inserter, as it manages the JTAG > linkages with the microblaze debug module for me > > b) I then have to run MAP, PAR, bitgen again. > > > All of the signals and elements of > > the design are shown in it, and you simply choose the signals to > > monitor. After you close the Inserter, go back to ISE, and re-fit. > > Re-fit - 10s of minutes. > > > From the ChipScope viewer, you can reconfigure the FPGA, then do an > > "Import" which lets you bring in the names of all of the signals you > > selected from the ChipScope Core Inserter project file. > > > No need to go into the FPGA editor at all! > > FPGAeditor, regenerate bitstream, 10s of seconds... =A0Then click "write > CDC" button, import the result into the analyser. =A0Still tedious :) > > As I recall my experience with SignalTap (which was a while ago > admittedly) I could select a signal from a dropdown list *in the > Analyser* and it would do the tedious hacking that I currently do in > FPGAed, regen the bitstream and upload it for me. > > Under some circumstances, it would redo a fit at that point, which was > irritating, but at least I was able to do it all from the analyzer GUI, > which was then always in sync with the FPGA. > > [Followups set to comp.arch.fpga, as it's not very Veriloggy] > > Cheers, > Martin > > Crosspost & Followup-To: comp.arch.fpga > -- > martin.j.thomp...@trw.com > TRW Conekt - Consultancy in Engineering, Knowledge and Technologyhttp://w= ww.conekt.net/electronics.htmlArticle: 144537
> >If your implementation comes out to be break before make, it's quite >easy to do. Assume the following implementation: > >wire o = (!s & a) | (s & b). > > If the inverter is slow enough, both and gates will have their select >inputs low when s changes high to low. >-- And to prevent glitches wire o = (!s && a) || (s && b) || (a && b). You may have to force your synthesis tool not to optimize out the redundant logic. --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 144538
On Dec 13, 6:13=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > > We don't have all the details of the OP's project. =A0It might > the data source is asynchronous, and that asynchronous FIFO > is the best choice. =A0 > I agree we don't have all the details, but he did post a link to the part that he's interfacing with and that part has a synchronous mode of operation that looks on the surface to be rather reasonable that runs at ~6x faster (peak). He's choosing to use the async mode of operation for reasons having nothing to do with performance because it simplifies other aspects. That's fine, but when you do deliberately give up chunks of performance for those reasons, don't quibble about another 'additional' bit in order to have a robust design. KJArticle: 144539
On Dec 13, 4:18=A0pm, "dlopez" <d...@designgame.ca> wrote: > > I would have to disagree with you here. There are two modes of operation > for this chip: > a) Synchronous: One channel at ~25MB/s. > b) Asynchronous: Two channels of max ~10MB/s. > > This means that the two modes are somewhat similar in terms of performanc= e, They don't seem that similar to me... > if one can achieve close to this maximum of 10MB/s. and it comes with a caveat. > ...makes software and > hardware developpement and architecture much easier. I accept that there may be a benefit to your decision here, the price being some amount of performance. As I mentioned in the first post is you have to do the analysis to see if the performance that you can get from async is acceptable or not. If it isn't, then making "developpement (sic) and architecture much easier" is a moot point. > > This sounds like a reasonnable decision, if I can live with the > asynchronous performance. In fact, I can, given I stay close to the 10MB/= s. Maybe ask what are the actual system consequences to 8...or 9? So much performance has already been left on the table already (30 MB/sec USB sustained system is achievable with other chips and designs). > I'm trying to find a circuit that will allow me to stay close to this, > without running at 500GHz, since I'm in a Spartan 3. Maybe 50M or 100M > would be good. > If I recall the spec numbers correctly, you need to guarantee a 50 ns pulse width and 33 ns dead time. Allowing 5 ns for Tco and another 5 ns for Tsu for the round trip means you need to generate a 60 ns pulse. An 80 MHz clock (12.5 ns period) would allow you to generate a 62 ns pulse with 37 ns dead time. Two synchronizing flops adds 25 ns for a total of 124 ns or an 8 MHz rate. Since ultimate performance is not your goal, cutting development time is (and that's fine, it can result in getting product sooner), getting 8 MHz out of this particular async interface is not too bad. KJArticle: 144540
Thanks a lot for your help with these settings. We finally got the color bar output pattern to display via DVI. It came down to not having the right timings on the DE line, it's amazing how precise everything has to be to work. I would like to post more info about using this chip after we get some video data input, and hopefully output :) --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 144541
Thanks, Brian! That's very helpful! EricArticle: 144542
Hi everyone, there has been a lot of talk about this same question I'm about to ask, but it is spread out over many different locations on the internet and I can't find a real answer... I am trying to interface the supplied 256MB DDR2 module (MT4HTF3264H-53E) with the XUPV5-LX110T board. I'm using EDK 10.1 and I can add an MPMC core, but the BSB only has the LX50T device listed, so when it runs MIG it creates a UCF file that gives the following error when compiled: ------------------------------------------------------------------------------ ERROR:Place:713 - IOB component "fpga_0_DDR2_SDRAM_DDR2_DQ<13>" and IODELAY component "DDR2_SDRAM/DDR2_SDRAM/mpmc_core_0/gen_v5_ddr2_phy.mpmc_phy_if_0/u_phy_io_0/g en_dq[13].u_iob_dq/u_idelay_dq" must be placed adjacent to each other into the same I/O tile in order to route net "DDR2_SDRAM/DDR2_SDRAM/mpmc_core_0/gen_v5_ddr2_phy.mpmc_phy_if_0/u_phy_io_0/g en_dq[13].u_iob_dq/dq_in". The following issue has been detected: Some of the logic associated with this structure is locked. This should cause the rest of the logic to be locked.A problem was found at site IODELAY_X0Y56 where we must place IODELAY DDR2_SDRAM/DDR2_SDRAM/mpmc_core_0/gen_v5_ddr2_phy.mpmc_phy_if_0/u_phy_io_0/ge n_dq[13].u_iob_dq/u_idelay_dq in order to satisfy the relative placement requirements of this logic. IODELAY DDR2_SDRAM/DDR2_SDRAM/mpmc_core_0/gen_v5_ddr2_phy.mpmc_phy_if_0/u_phy_io_0/ge n_dqs[0].u_iob_dqs/u_iodelay_dq_ce appears to already be placed there which makes this design unplaceable. ------------------------------------------------------------------------------ There has been the suggestion that opening CORE generator and creating a new MIG project (MIG v2.3 in my case) may work because it does contain the LX110T device. However, this new file needs to have its LOC constraints changed as well to specifically fit the XUPV5-LX110T board. Can somebody point me in the right direction for fixing this, maybe I just need to learn more about I/O tiles, banks, and what it means to have "Some of the logic associated with this structure locked". ANY help would be greatly appreciated, Thanks --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 144543
On Dec 11, 6:07=A0pm, Mike Treseler <mtrese...@gmail.com> wrote:
> True, but it simplifies simulation having a reset
> for the input and output registers, even if (especially if ?)
> the rams and some shifters don't have one.
I agree that it's a Very Good Idea to have a reset, but I don't see
why it has to be an asynchronous one. By default I try to make
everything synchronous, including resets, unless there is a strong
case to do otherwise. I have found that this leads to fewer problems
throughout implementation.
-Ben-
Article: 144544Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de> writes: > I always bug Xilinx on fairs to document the interfaces, but while I would rather want the ability to add a plug-in at the software level. I can program FPGA's fine with my Ethernet based "programming cable", but I can't interface to chipscope and signaltap. A documented USB interface would not be optimal in my case as I would have to make a some kind of virtual USB device. It would be more optimal to have some method at the Impact/quartus_pgm level to add a programming hardware interface. Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 144545
hello, I am using spartan 3 starter board (with MB7.1) to work with 2 processors cores using EDK10.1 (my reference is the Xilinx tutorial XAPP996). I want to add, between the two processors, a shared memory BRAM_block_v1_00_a with the controler xps_bram_if_cntlr_v1_00_a. the problem is: when I want to share the bus of the bram controller SPLB, changing the parameter C_SPLB_P2P to 0, nothing happens and the SPLB bus does not connect the two buses mb_plb_0 and mb_plb_1 respectively of the fist CPu and the the second. if someone has an idea please help me because I'm stuck. :( Thanks in advance INES --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 144546
On Sun, 13 Dec 2009 13:47:09 -0600, "jt_eaton" wrote: >>wire a = b ? 1 : count[0]; > >And this differs from > >wire a = b || count[0]; > >How? Legibility? Clarity of design intent? Yes, I know these are niminy-piminy concerns that do not trouble Real Designers, but personally I'm fairly happy to be a Quiche Eating Designer. If there were more Quiche Eating and fewer Real Designers in the RTL business, I suspect the verification business would be less able to find work for me to do. Cheers! -- Jonathan BromleyArticle: 144547
Petter Gustad <newsmailcomp6@gustad.com> wrote: > Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de> writes: > > I always bug Xilinx on fairs to document the interfaces, but while > I would rather want the ability to add a plug-in at the software > level. I can program FPGA's fine with my Ethernet based "programming > cable", but I can't interface to chipscope and signaltap. A documented > USB interface would not be optimal in my case as I would have to make > a some kind of virtual USB device. It would be more optimal to have > some method at the Impact/quartus_pgm level to add a programming > hardware interface. Interface was meant here as the software interface, API should have been better uses instead of interface... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 144548
On Mon, 14 Dec 2009 01:02:25 -0800 (PST), Ben Jones <benjjuk@gmail.com> wrote: >On Dec 11, 6:07 pm, Mike Treseler <mtrese...@gmail.com> wrote: > >> True, but it simplifies simulation having a reset >> for the input and output registers, even if (especially if ?) >> the rams and some shifters don't have one. > >I agree that it's a Very Good Idea to have a reset, but I don't see >why it has to be an asynchronous one. By default I try to make >everything synchronous, including resets, unless there is a strong >case to do otherwise. I have found that this leads to fewer problems >throughout implementation. For most of the design I would agree. I confess I once had trouble with synchronous resets on clock generators, DCMs and the like. (The clock stops, so they never come out of reset.) So there are occasional roles for asynch reset... - BrianArticle: 144549
Hi, I want to send a video file from a pc to a FPGA (on a XUPV2P development board) via the PCI interface. On the FPGA the video will be processed by an algorithm. The result, after processing, will be send back to the pc. I generated the VHDL-code of the algorithm in Simulink with Xilinx System Generator (gateway_in and gateway_out are 8 bits wide). I also have the VHDL-code of the PCI-core (from Xilinx). In Xilinx ISE I instantiated the algorithm in the PCI-code. The resolution of the video is 320x240. The device driver on the pc (Linux) gives an interrupt at the beginning of every frame. Can someone tell me how I have to adapt the code of the user application delivered by Xilinx ( code can be found here : http://www.mediafire.com/?kyygtdm0wlj ) to give the FPGA a sign to start processing the data and send the result back to the pc after a frame has been processed? Is there a manner to check how many bits/bytes/pixels passed by? 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