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
. . >too small, or the excessive delay if the resistor value is too high. >And all of this only works if there is a clamp diode to Vc (and the >supply can absorb the current, especially from many pins). >We just hope that 5-V soon becomes a relic of the past, same as 12 V >became obsolete long ago... Ie DTL/RTL logic?Article: 130401
I am testing the async_transmission module in xilinx webpack. But I couldn't see the waveform demonstrated in the tutorial for 0x01010101. TxD is always 'x' in my behavioral simulation, what's wrong? It seems as if the transmission module never sees the TxD_start turns high. Attached is the source code for the async_transmission and my test module. Thanks, `timescale 1ns / 1ps `define DEBUG // in DEBUG mode, we output one bit per clock cycle module serial_tx(clk, TxD_start, TxD_data, TxD, TxD_busy); input clk, TxD_start; input [7:0] TxD_data; output TxD, TxD_busy; parameter ClkFrequency = 25000000; // 25MHz parameter Baud = 115200; parameter RegisterInputData = 1; // in RegisterInputData mode, the input doesn't have to stay valid while the character is been transmitted // Baud generator parameter BaudGeneratorAccWidth = 16; reg [BaudGeneratorAccWidth:0] BaudGeneratorAcc; `ifdef DEBUG wire [BaudGeneratorAccWidth:0] BaudGeneratorInc = 17'h10000; `else wire [BaudGeneratorAccWidth:0] BaudGeneratorInc = ((Baud<<(BaudGeneratorAccWidth-4))+(ClkFrequency>>5))/ (ClkFrequency>>4); `endif wire BaudTick = BaudGeneratorAcc[BaudGeneratorAccWidth]; wire TxD_busy; always @(posedge clk) if(TxD_busy) BaudGeneratorAcc <= BaudGeneratorAcc[BaudGeneratorAccWidth-1:0] + BaudGeneratorInc; // Transmitter state machine reg [3:0] state; wire TxD_ready = (state==0); assign TxD_busy = ~TxD_ready; reg [7:0] TxD_dataReg; always @(posedge clk) if(TxD_ready & TxD_start) TxD_dataReg <= TxD_data; wire [7:0] TxD_dataD = RegisterInputData ? TxD_dataReg : TxD_data; always @(posedge clk) case(state) 4'b0000: if(TxD_start) state <= 4'b0001; 4'b0001: if(BaudTick) state <= 4'b0100; 4'b0100: if(BaudTick) state <= 4'b1000; // start 4'b1000: if(BaudTick) state <= 4'b1001; // bit 0 4'b1001: if(BaudTick) state <= 4'b1010; // bit 1 4'b1010: if(BaudTick) state <= 4'b1011; // bit 2 4'b1011: if(BaudTick) state <= 4'b1100; // bit 3 4'b1100: if(BaudTick) state <= 4'b1101; // bit 4 4'b1101: if(BaudTick) state <= 4'b1110; // bit 5 4'b1110: if(BaudTick) state <= 4'b1111; // bit 6 4'b1111: if(BaudTick) state <= 4'b0010; // bit 7 4'b0010: if(BaudTick) state <= 4'b0011; // stop1 4'b0011: if(BaudTick) state <= 4'b0000; // stop2 default: if(BaudTick) state <= 4'b0000; endcase // Output mux reg muxbit; always @( * ) case(state[2:0]) 3'd0: muxbit <= TxD_dataD[0]; 3'd1: muxbit <= TxD_dataD[1]; 3'd2: muxbit <= TxD_dataD[2]; 3'd3: muxbit <= TxD_dataD[3]; 3'd4: muxbit <= TxD_dataD[4]; 3'd5: muxbit <= TxD_dataD[5]; 3'd6: muxbit <= TxD_dataD[6]; 3'd7: muxbit <= TxD_dataD[7]; endcase // Put together the start, data and stop bits reg TxD; always @(posedge clk) TxD <= (state<4) | (state[3] & muxbit); // register the output to make it glitch free endmodule module serial_tx_tb(); reg clk; reg [7:0] data; reg tx_start; wire tx, tx_busy; serial_tx si(clk, tx_start, data, tx, tx_busy); initial begin clk = 1'b0; forever #20 clk = ~clk; end initial begin data = 8'b01010101; #100 tx_start = 1'b1; end endmoduleArticle: 130402
Hi all, I am simulating a entity with Modelsim via Xilinx Webpack. Modelsim only displays the input/output signals of the simulated top entity. Is there a way of viewing the internal signals declared in the architecture of the entity without adding them to the port outputs of the simulated top entity? Thanks very much Regards JosephArticle: 130403
On Mar 21, 4:12 pm, "Giuseppe Marullo" <giuseppe.marullospam...@iname.com> wrote: > First of all thank you all for your answers. > > >This one??http://www.knjn.com/docs/KNJN%20FX2%20ARM%20boards.pdf > > Yes, maybe this pdf explains better the FPGA part (it has an ARM also):http://www.knjn.com/docs/KNJN%20FX2%20FPGA%20boards.pdf > > It says it is a Spartan XC3S500E (speed grade -4) in a pq208 package. > Very nice board, I am already able to talk with the FPGA thru the USB2.0 > with a Delphi program. > This was my major concern, I wanted a easy way to exchange data with the pc, > and so far I was right. > > >We use bus switches for this type of problem. Have a look at the > >schematics for our obsolete component replacement family Craignell > >http://www.enterpoint.co.uk/component_replacements/craignell.html > >where we have exactly this problem where we need to make a Spartan-3E > >to be 5V tolerant but also need to achieve 5V CMOS levels on outputs > >to the outside world. > > >John Adair > >Enterpoint Ltd. > > Curious, I was writing a good idea could be to use the PCI bus interface of > the Raggedstone (QS386PA), I guess Craignell uses a similar one (QS32X361?) > . > > If I understand correctly, they should work bidirectionally, or it seems to > good to be true? Bidirectional, automatic, zero delay... > > There are just two drawbacks for me: > > 1) I need to find them at reasonable price in Italy in low qty > > 2) I need to build a smd pcb (no DIL package I suppose) > > Other than this they should solve my problem, no messing with resistors and > currents bla bla. > > Giuseppe Marullo Perhaps something more conventional, like a 74LVX3245?Article: 130404
"Joseph" <jozamm@gmail.com> wrote in message news:12d475c1-5c84-48fd-8ef3-c49357b06f42@2g2000hsn.googlegroups.com... > Hi all, > > I am simulating a entity with Modelsim via Xilinx Webpack. Modelsim > only displays the input/output signals of the simulated top entity. > > Is there a way of viewing the internal signals declared in the > architecture of the entity without adding them to the port outputs of > the simulated top entity? > > Thanks very much > > Regards > > Joseph Modelsim will optimise your design by default and hence you might loose some internal signals, try "log -r *" before running your simulation. Hans www.ht-lab.comArticle: 130405
On Fri, 21 Mar 2008 18:22:49 -0600, <steve.lass@xilinx.com> wrote: >No SV yet. I find that a tad disappointing. I'm sure X has done its market research, but from my point of view I see so many potential benefits to designers from adopting SV... and the FPGA community has traditionally been much more willing to adopt interesting language features for design, whereas the ASIC community tends to be rather conservative because it sees most of its problems as being downstream of the design phase. The part I find frustrating is that the real gains from SV come only when an implementation (of the design subset) is reasonably complete. Chipping away at the edges (as some vendors initially did), by implementing always_ff and a few easy data types, doesn't get us anywhere in terms of real design capability. My hit-list... full support for enums, including traversal methods packed structs and unions interfaces, ** including modport expressions ** unique/priority always_comb When completed, this gives you a design language with significantly better expressive power than VHDL in some areas. ~~~~~~~~~~~~~~~~ Finally, a minor correction for the record: > You will have to get that from our partners > (I guess that would be Synopsys if you're > looking for SV synthesis). SV synthesis is competently supported not only by Synopsys DC but by at least one of the major third-party FPGA synthesis tools. The other obvious third-party FPGA synth tool makes a reasonable attempt at SV, **as does the free tool of your obvious competitor**. ~~~~~~~~~~~~~~~~~~~~~~~ Big whinge time: AFAIK NO synthesis tool yet supports modport expressions, the SV feature that has most impact in providing new expressive power for re-usable, parameterised design. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 130406
> Perhaps something more conventional, like a 74LVX3245? The simplicity of the IDC part is irresistable, no OE and no direction pins, no added delay, really neat.Article: 130407
On 14 Mrz., 07:14, Antti <Antti.Luk...@googlemail.com> wrote: > Hi > > I wonder if anyone had any success using either DirectC 2.2 or SVF > files to program Actel PA3 devices. All my attempts are failing so > far. > > 1) DirectC 2.2 compiled with VC2005 (adapted to Xilinx Cable III), had > 1 time success from 100 attempts to program the part > 2) playing SVF or XSVF files with Impact fail very quick, SVF doesnt > even get as far as checking jtag IDCODE > 3) custom SVF player also shows weird behaviour > > Antti I must answer solve myself, here are reports PCB1_a3p250 - directc 2.2 programmed 100% one time out of 150, 149 times fail very quick (first commands already) - flashpro - FAIL (bad response for enter isp) PCB2_a3p060 - directc 2.2 DEBUG Build, works 100% each time - directc 2.2 RELEASE Build works maybe 1 of 10, when fails the enter_isp mode - flashpro - works so it does look like some problem related to the chip or wiring or powersupply, still little strange that the release-debug setting while compiling directC makes so big difference AnttiArticle: 130408
We have now publically released the pricing for Raggedstone1 for OEM quantity pricing and for all those that keep asking we have added now an "I" option for OEM. Details here http://www.enterpoint.co.uk/moelbryn/raggedstone1.html. University and student pricing is also available though our university program UAP. Another item often asked for is a high speed USB. We should be be releasing a USB module shortly based on the Cypress CY7C68014 to support Raggedstone1 and allowing a fairly high speed connection to PCs etc.. This module will also be suitable for Broaddown2, Broaddown4 and when we finally let it out the door Broaddown3. John Adair Enterpoint Ltd.Article: 130409
Joseph wrote: > Hi all, > > I am simulating a entity with Modelsim via Xilinx Webpack. Modelsim > only displays the input/output signals of the simulated top entity. > > Is there a way of viewing the internal signals declared in the > architecture of the entity without adding them to the port outputs of > the simulated top entity? > Sorry if this is obvious, but you have tried descending the hierarchy in the "Workspace" window? Signals at the current level are listed in "Objects", & you can add them to the display.Article: 130410
On Tue, 18 Mar 2008 23:31:09 GMT, "KJ" wrote: [I wrote:] >> I know of several tools that *do* support [VHDL 'pos and 'val attributes] >And apparently you don't want to name the several tools that you know that >do support it even while asking others for that same info ;) No, indeed I don't. If I say (truthfully) "tools A and B support feature F", and it happens that tool C also supports feature F, then vendor C is quite likely to give my employer a hard time for the perceived unfair publicity. I would much prefer to say "some tools support feature F", and allow people to find out for themselves from their chosen (or candidate) vendors if it matters to them. If I were to get involved in "who supports what" feature comparisons, I would be duty bound to be far more thorough and careful than would ever be possible in a newsgroup posting. In particular, I would need to prepare my comparisons and submit them to all the vendors before publication so that they could correct any factual inaccuracies before going to press. I have no desire to be a stooge of any of the tool vendors, but it is also very important to me and to my employer that we treat them all fairly. We cannot avoid discussing specific tools as part of our training courses, and we must scrupulously avoid bias. By contrast, a customer of one single vendor has (almost) no such obligation of impartiality and, give or take a few legalistic constraints, can say whatever they want about the tool they have purchased. Sorry to disappoint :-) -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 130411
Hey, I want to read an 8bits data from a memory at 500MHz and want to send this serially at a speed of 4GBits/s. I am reviewing the documents. What are the possible solutions for that memory read write operation and data transfer operation. I am reviewing the userguides of rocket io tranceiver modules and what i see is a maximum transfer rate of 3.125GBits/sec per one channel and 2.5GBits/s payload. What i have to do is to reach the speed of at least 4GBits/sec. Is there a solution ? Regards, AnilArticle: 130412
"anilcelebi" <anilcelebi@gmail.com> wrote in message news:eee7562c-61c7-4151-b1ee-7b03e445868d@s12g2000prg.googlegroups.com... > Hey, > > I want to read an 8bits data from a memory at 500MHz and want to send > this serially at a speed of 4GBits/s. I am reviewing the documents. > What are the possible solutions for that memory read write operation DDR2 or 3 is about the only choice then for the memory if you absolutely have to have only 8 bit wide memory. Widen the memory path to 16 bits and you can use DDR. You didn't mention if the 500 MB/sec read rate is intended to be a burst rate or a continuous rate. If it's continuous, then it makes no sense to read out at 500 MB/sec unless you're also writing to it at 500 MB/sec which means a minimum memory bandwidth requirement of 1GB/sec. Add on 1-2% for refresh and then 5% for a decent and efficient arbitration algorithm (assuming reads and writes need to overlap). If the 500 MB/sec rate is some burst and it is acceptable to block all write access during the transfer then of course none of that applies. > and data transfer operation. I am reviewing the userguides of rocket > io tranceiver modules and what i see is a maximum transfer rate of > 3.125GBits/sec per one channel and 2.5GBits/s payload. What i have to > do is to reach the speed of at least 4GBits/sec. Is there a solution ? A second channel. Kevin JenningsArticle: 130413
Anil, Use two channels. AustinArticle: 130414
Antti wrote: > I have been think and part time working towards a goal to make useable > and useful serialized processor. I had a fair amount of experience with a serial processor in college -- a donated Bendix G-15, with rotating drum for the main store and vacuum tube logic circuits. It was a clever bit serial design, with lsb first. Everything was clocked to the rotating drum. Left shift was done with a clock delay and right shift done with a "short line" that only had 55 bits instead of the usual 56 bits for a double word register. The University of Colorado had an experimental optical computer that was bit serial for cost reasons. It used 23 gates, IIRC, which were very expensive. -- ThadArticle: 130415
On Mar 19, 7:28 am, Antti <Antti.Luk...@googlemail.com> wrote: > Hi > > I have been think and part time working towards a goal to make useable > and useful serialized processor. The idea is that it should be > > 1) VERY small when implemented in any modern FPGA (less 25% of > smallest device, 1 BRAM) > 2) be supported by high level compiler (C ?) > 3) execute code in-place from either serial flash (Winbond quad speed > SPI memory delivers 320 mbit/s!) or from file on sd-card > > serial implementation would be smaller and run at higher speeds, so > 128 clock per machine cycle would already mean 2 MIPS, what would be > acceptable for many applications. I wonder what the optimization target is? Size? I am pretty sure that at some point the overhead of handling a serial datapath exceeds the benefits. eg I would assume that a 2 or 4 bit datapath does actually use fewer resources than a 1 bit datapath. Or is the defining target the ability to execute program from a serial memory device? In that case one may wonder how suboptimal it would really be to use an existing parallel design and add some par/serial conversion logic.Article: 130416
On Mar 22, 12:33 am, Fei Liu <fei....@gmail.com> wrote: > I am testing the async_transmission module in xilinx webpack. But I > couldn't see the waveform demonstrated in the tutorial for 0x01010101. > TxD is always 'x' in my behavioral simulation, what's wrong? It seems > as if the transmission module never sees the TxD_start turns high. > > Attached is the source code for the async_transmission and my test > module. > > Thanks, > > `timescale 1ns / 1ps > `define DEBUG // in DEBUG mode, we output one bit per clock cycle > > module serial_tx(clk, TxD_start, TxD_data, TxD, TxD_busy); > input clk, TxD_start; > input [7:0] TxD_data; > output TxD, TxD_busy; > > parameter ClkFrequency = 25000000; // 25MHz > parameter Baud = 115200; > parameter RegisterInputData = 1; // in RegisterInputData mode, the > input doesn't have to stay valid while the character is been > transmitted > > // Baud generator > parameter BaudGeneratorAccWidth = 16; > reg [BaudGeneratorAccWidth:0] BaudGeneratorAcc; > `ifdef DEBUG > wire [BaudGeneratorAccWidth:0] BaudGeneratorInc = 17'h10000; > `else > wire [BaudGeneratorAccWidth:0] BaudGeneratorInc = > ((Baud<<(BaudGeneratorAccWidth-4))+(ClkFrequency>>5))/ > (ClkFrequency>>4); > `endif After a lot of debugging, it seems the incremental variable BaudGeneratorInc calculation is not working with ise webpack. The following formula is simpler to understand and yields correct result: wire [BaudGeneratorAccWidth:0] BaudGeneratorInc = (1<<BaudGeneratorAccWidth)/(ClkFrequency/Baud);Article: 130417
Three tools can be very useful when chasing down timing issues: 1) trace (timing) report: generally, look to see the failing time specs; when you run it with useful options, you can get a feel for the critical path 2) delay report: sort of a netlist, marginally readable... but used in conjunction with the timing report, you can see variations on delays on any common net, which may give a clue to location issues causing the timing problems. You can also see how your clocks are routed; i.e, which BUFGs are used, etc. 3) the FPGA Editor: for small designs, you could go here quickly; however, for large designs, it takes a long time to load, so I avoid it as much as I can. But when you have to do it, do it with the report information handy. It can then be used as a reference for manual floorplanning (as in, seeing how the tool did a lousy job, and then picking [better] fixed locations for a few critical points (e.g., BUFGs, FFs.) A fourth 'tool' is the data sheet for the part. All the timing definitions (tco, tpd, tsu, ...) are defined there; when you run across an unfamiliar one in the timing report, refer to the data sheet. Sometimes the problem is as simple as forcing a register to be in, or out of, an IOB. The results of this analysis should guide you in further decision-making: 1) Floorplanning. 2) Re-coding portions of the design to make the critical path(s) non-critical. 3) Adding (or removing) timing constraints, such as multi-cycle constraints or Timing Ignore constraints. 4) Telling the tool to work harder, because the solution is there... 5) Recognizing that you just can't get there from here, and accepting lower peformance. I try to avoid #5 by identifying critical paths early in the design process; I like to have some realistic expectation of success when I sign up to do something. Nevertheless, there frequently arise cases where "sometimes it meets timing easily, sometimes it doesn't meet it at all." I.e., after minor design changes, timing closure may fail miserably. Usually, I end up asking myself, "How did the tool manage to do such a lousy job?" By inspecting the timing report, I can see whether the problem is likely too many levels of logic, or just plain lousy mapping and placement, where the routing process just can't make meet timing. (I have seen this happen many, many times over the last 10+ years.) When I look at the [failing] timing report, I try to find answers to a few key questions (not necessarily in any order): 1) Do the failures have something in common? E.g, there might by 165,000 nets failing timing, but the worst 20 (or 7,000, or...) are all part of the same bus. The routing tool will often stop optimizing as it focuses all of its attention on the worst ones, making the problem seem worse than it really is. 2) Are there outlandishly long routing delays between logic elements? This is often indicative of poor placement, or not using preferred routing resources, such as between pins, BUFGs, and DCMs. 3) In conjuction with the delay report, are the delays on a net roughly matched for all nodes, or are some way off base? This kind of information gives a clue as to what you might see if you open the routed design with the FPGA Editor. 4) Are the failures real? I have often had control path failures because I had not initially used appropriate mutli-cycle constraints. (Of course, sometimes I had to change the design to force them to be multi-cycle. Give and take.) As to examples, the ones that mean the most to you will be the ones for your design.... If you are overwhelmed with what you have at the moment, create a tiny design, over-constraint it (say, 2 GHz?), and try to make sense of the report. (Or, just have the timing tool report all paths in detail, not just the failing paths.) JTW <u_stadler@yahoo.de> wrote in message news:ae7fc722-f000-44a5-b852-7d53946cb99d@x41g2000hsb.googlegroups.com... >i forgot mention that i did a static timing analysis with the timing > analyzer. > i also looked into the manual for trace but i would rather have some > examples if there are some. > thanksArticle: 130418
On Mar 22, 11:59 pm, austin <aus...@xilinx.com> wrote: > Anil, > > Use two channels. > > Austin A second channel sounds great but what i can understand from the rocketIO user guides is that i am not allowed to split the data smaller than 8 bits such as "two 4 bits". If it is possible to send a 4 bits of data through one channel please refer the data sheet or any other documents. One more question is that, can i implement the whole system control by custom logic or should i try to use a ppc or microblaze design.Article: 130419
On Mar 22, 11:58 pm, "KJ" <kkjenni...@sbcglobal.net> wrote: > "anilcelebi" <anilcel...@gmail.com> wrote in message > > news:eee7562c-61c7-4151-b1ee-7b03e445868d@s12g2000prg.googlegroups.com... > > > Hey, > > > I want to read an 8bits data from a memory at 500MHz and want to send > > this serially at a speed of 4GBits/s. I am reviewing the documents. > > What are the possible solutions for that memory read write operation > > DDR2 or 3 is about the only choice then for the memory if you absolutely > have to have only 8 bit wide memory. Widen the memory path to 16 bits and > you can use DDR. What i tried to explain by saying 8 bits and 500MHz is the speed i need. It can also be 250 MHz 16 bits and 125 MHz 32 bits. The data width is limited by the rocket IO tranceivers tha the fpga have. I will possibly use the smallest Virtex IV FPGA with the MGTs. It has too much speed options for data transfer and i am trying to find the best choice. > You didn't mention if the 500 MB/sec read rate is intended to be a burst > rate or a continuous rate. If it's continuous, then it makes no sense to > read out at 500 MB/sec unless you're also writing to it at 500 MB/sec which > means a minimum memory bandwidth requirement of 1GB/sec. It is only the burst read rate. Read and write operations will be performed independently. >Add on 1-2% for > refresh and then 5% for a decent and efficient arbitration algorithm > (assuming reads and writes need to overlap). If the 500 MB/sec rate is some > burst and it is acceptable to block all write access during the transfer > then of course none of that applies. > > > and data transfer operation. I am reviewing the userguides of rocket > > io tranceiver modules and what i see is a maximum transfer rate of > > 3.125GBits/sec per one channel and 2.5GBits/s payload. What i have to > > do is to reach the speed of at least 4GBits/sec. Is there a solution ? > > A second channel. > > Kevin Jennings As i understand from the user guides and datasheets i am not allowed to split the data smaller than 8 bits. So the maximum rate to serially send an 8 bits data is 2.5Gbit/s. If i am wrong please correct my mistake and refer some data sheets related to the solution. Regards...Article: 130420
On 22 Mrz., 00:44, alud...@altera.com wrote: > As of the latest release of Quartus II, you'll get an average speedup > of about 15% on two processors and 20% on four. I guess a theoretical computer scientist would call that "not parallelizable". 20% on four processors is hardly impressive and should be possible be rewriting the makefile alone. If you spent the same human ressources on optimizing the serial algorithms, don't you think a 15% speedup on a single processor would have been possible? Also 15% speedup ist the same as pruchasing the CPU three months later. A note on the algorithms: I you used an quadratic placer, you could parallize the matrix operation while running the main algorithm on only one processor. Kolja SulimmaArticle: 130421
On 23 Mrz., 09:12, anilcelebi <anilcel...@gmail.com> wrote: > As i understand from the user guides and datasheets i am not allowed > to split the data smaller than 8 bits. So the maximum rate to serially > send an 8 bits data is 2.5Gbit/s. If i am wrong please correct my > mistake and refer some data sheets related to the solution. I am not sure that I understand the question. The V4 MGTs allow user side data busses of 8 bits to 64 bits. For any of these user side widths a wide range of serial data rates are possible up to 6.5gbps (for higher speedgrades). The user bus frequency is determined (using 8b10b encoding) by (serial link rate/10)/number of bytes on user bus The interpretation of the data on the user bus is up to the user. You can treat it as a stream of nibbles, a stream fo 16-bit words, whatever. The only restriction is that comma words will alwas take up 8 bits and will be byte aligned. (But hey, that could be a two-nibble-comma) So you can very well send a stream of nibble through a V4 MGT. And you can run a single link at the 5gbps necessary for your application if you choose a higher speedgrade. Kolja SulimmaArticle: 130422
On Mar 20, 1:09 am, "David Binnie" <td.bin...@blueyonder.co.uk> wrote: > The Virtex2Pro board is not recognised by the latest version of EDK (9.2i) > > If you want larger memory the V2P DDR memory interface requires specialist > support. > Digilent nor Xilinx will not give you a working example. > > Strongly suggest Spartan 3A board instead. hmm, there are basically two reasons we want to use FPGA board in our robotics club of our college: i) We want to make SOC designs used for image processing, path planning, motion control for our robots which need both processor and dedicated hardware. Since this type of design has not been used so far here, we are actually trying to introduce it and hence finding it difficult to select the best way. Once started it will continue with newer students every year. ii) We want to complete a project with a working robot that could track some colored object or some specific shaped object. Finding such object in a room. Your suggestions for the board have been helpful and I hope I'll get more insight with a bit more discussion. Thank you.Article: 130423
On Mar 20, 6:52 pm, Dave Pollum <vze24...@verizon.net> wrote: > On Mar 20, 2:48 pm, Dave Pollum <vze24...@verizon.net> wrote: > > > On Mar 20, 2:11 pm, Dave Pollum <vze24...@verizon.net> wrote: > > > > I'm trying to run the Xilinx version of Modelsim (XE III 6.2g), and it > > > displays everything in HUGE fonts. On my 21" monitor, each char is at > > > least 1" tall. This happens whether I run Modelsim by itself, or when > > > I run it from ISE Webpack 9.2.04i. I've downloaded the latest > > > versions of both ISE Webpack and Modelsim XE from Xilinx's web site. > > > I tried searching Xilinx's website but didn't find any answers. If I > > > can find an older version of Modelsim, I'll try that, but I'm not sure > > > where to download it from. > > > TIA > > > -Dave Pollum > > > I forgot to mention that I'm running Windows 2000 Prof, SP4. > > -Dave Pollum > > I uninstalled the video card and then re-installed the video card > software. When I ran Modelsim (stand alone), the fonts were correct. > But the second time I ran Modelsim, the fonts were huge again. As > before, the character fonts had large pixels. > -Dave Pollum I've tried ISE WebPack 9.2x with ModelSim XE II starter 5.8c and that combo works. It still puzzles me that a newer version of ModelSim acts so oddly. -Dave PollumArticle: 130424
On Mar 3, 10:22 am, "BobW" <nimby_NEEDS...@roadrunner.com> wrote: > "Antti" <Antti.Luk...@googlemail.com> wrote in message > > news:ee42d07c-3062-489e-93b1-d9afa01fbbac@y77g2000hsy.googlegroups.com... > > > > > On 3 Mrz., 17:15, Kolja Sulimma <ksuli...@googlemail.com> wrote: > >> On 3 Mrz., 11:20, Antti <Antti.Luk...@googlemail.com> wrote: > > >> > but as the V5FX has been delaying so long, I have almost lost interest > >> > to follow up how much longer it is delaying in reality... > > >> > The Spartan-4 is much more interesting, > > >> Well, we are desperately waiting for the V5 MGTs. > >> Actually we need a solution for 10gbps soon as XAUI is going to be > >> replaced > >> by SFP+ really soon. We can't place external 10G serdes on 12 ports. > > >> Kolja Sulimma > > > well EVERY new xilinx family since V2ProX is DOWNGRADING the speed of > > MGTs > > V4 less than V2 > > V5 less than V4 > > > so you may need wait V6 :( > > > Antti > > V6? Don't hold your breath. > > A reliable source tells me that the 10Gbps serdes will be fully functional > in V12 Pro (they're skipping V13 for obvious reasons). > > Bob I would check with Altera on Serdes as they have done it right and have been up to 6 Gbps for years.
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