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
Tim Verstraete wrote: > Hey, > > Do some of you also have a problem with adding probes in fpga editor and > then generating the bit file? i have the same problem sometimes with > chipscope (especially when i assigned the wrong one and then change it back > to the right one and then generate the bit file) .... when i generate the > bit file in those 2 situations the fpga editor just closes and crashes ... > Yes, after adding probes in the 7.1 version of fpga editor, trying to generate a bitfile crashes every time for me. And that is both using the Linux and the Windows version of fpga_editor. I have not messed with the 7.1 version of Chipscope yet, but I guess I'll have a chance to check out the crashing there soon.Article: 89201
All, Check out the comp.arch.fpga thread entitled "Virtex4 running at 360Mhz DDR" for a discussion about this stuff. I can't be arsed to explain _again_ that a 50 ohm line driving 12pF has the same rise time as a 100 ohm pair driving 6pF. Paul, IIRC, the Spartan parts you mention don't have on-chip resistive (100 Ohm) termination, so you need to provide this externally. HTH, Syms "Austin Lesea" <austin@xilinx.com> wrote in message news:dfn7t6$60a3@cliff.xsj.xilinx.com... > All, > > The LVDS input is 5 pF + 100 ohms. Differential input is really two > 10pF in series. > > So, for highest speed, the differential input is the best. > > Austin >Article: 89202
Roger wrote: > I'm just starting out using RIO on VII Pro devices and I need some simple > VHDL to get started. There are some code snippets in the RIO UG but I don't > think it's complete by any means. I just need something that generates some > data (probably with the Aurora primitive) so that I can test the hardware > it's running on and see what's required to be implemented in user code e.g. > SOP, EOP delimiter insertion, comma handling etc. > The Aurora "primitive"? The aurora core is not a primitive, so I am guessing you have not generated an Aurora core? When you generate the core, an example program is created, in a subdirectory named "examples". It is a very basic example, so simulate it and see what happens. If you have not already done so, go to the Xilinx website and register for access to the Aurora core. That will get you a license to use in coregen. Once that license is installed, run coregen and go to Communications...->Serial Interfaces->Aurora 2.3 Run Customize. Do not worry about the License Status message box; it is really referring to the RocketIO core, which is a primitive (the Aurora core uses the RocketIO primitive). For the easiest example, select Desired target device VHDL or Verilog Lane width 2 Interface framing Leave the "TX only" box on, which contrary to expectations, actually generates a bidirectional link. I have no idea why. Turn off native flow control Turn off user flow control Next-> Select row 1 clock BREF_CLK - this is actually determined by what pins the RocketIO clock is connected to In Row 1, enter a 1 in the first box and leave the others as X's Generate the core. Simulate.Article: 89203
"Duane Clark" <dclark@junkmail.com> wrote in message news:V6ITe.1881$7D1.660@newssvr12.news.prodigy.com... > Roger wrote: >> I'm just starting out using RIO on VII Pro devices and I need some simple >> VHDL to get started. There are some code snippets in the RIO UG but I >> don't think it's complete by any means. I just need something that >> generates some data (probably with the Aurora primitive) so that I can >> test the hardware it's running on and see what's required to be >> implemented in user code e.g. SOP, EOP delimiter insertion, comma >> handling etc. >> > > The Aurora "primitive"? The aurora core is not a primitive, so I am > guessing you have not generated an Aurora core? When you generate the > core, an example program is created, in a subdirectory named "examples". > It is a very basic example, so simulate it and see what happens. > > If you have not already done so, go to the Xilinx website and register for > access to the Aurora core. That will get you a license to use in coregen. > Once that license is installed, run coregen and go to > Communications...->Serial Interfaces->Aurora 2.3 > Run Customize. Do not worry about the License Status message box; it is > really referring to the RocketIO core, which is a primitive (the Aurora > core uses the RocketIO primitive). > For the easiest example, select > Desired target device > VHDL or Verilog > Lane width 2 > Interface framing > Leave the "TX only" box on, which contrary to expectations, actually > generates a bidirectional link. I have no idea why. > Turn off native flow control > Turn off user flow control > Next-> > Select row 1 clock BREF_CLK - this is actually determined by what pins the > RocketIO clock is connected to > In Row 1, enter a 1 in the first box and leave the others as X's > Generate the core. > Simulate. Duane, Thanks for your reply. I now see the problem - I don't have CoreGen as I'm just running the WebPack version of ISE (I want to target a VP2 device which the WebPack version supports). What you've kindly described sounds just what I need so it looks like I'll have to upgrade the tools first. Thanks, Roger.Article: 89204
Mike Treseler wrote: > CMOS wrote: >> im wondering whether there is a point in using 8087 Math Co-Processor >> in this FPGA Age? > No. Throw it away. > You would need an 8086 style interface just to talk to it. The 80287 interface might be a little easier. The 8087 worked by snooping the bus while the 8086 was running, then when it saw an 8087 opcode being fetched went on to fetch the rest of the bytes/words it needed. The 80287, I believe, worked in the more obvious way where the processor wrote/read from it. The 80287 also has a clock asynchronous to the bus interface, which might make it easier. Doing floating point in an FPGA tends to use a lot of CLBs, especially for add/subtract which seem easy. But one might be able to do an iterative implementation faster than the 80287, or a fully pipelined one at full speed. -- glenArticle: 89205
austin wrote: (snip) > Thanks for all who posted. > I still claim that by instantiating more than one core in an FPGA, they > still win oven even the best uP, however. > Massive parallelism is of course nearly impossible to use effectively, > as there is no language that preserves if operations could be done in > parallel. > We are stuck with a "paper tape" programming mentality in a > flash memory age. I like systolic arrays, though as you say there is no good language to write them in. -- glenArticle: 89206
wire signed [9:0] op1; assign op1 = subtract_u11[9:0]; assign add_u3 = 12'sh7E1 + multiply_u3_b_signed; 0x7E1 is a signed constant by definition of the 's news.green.ch wrote: > Hi > I'am a newbe, and know how to add unsigned numbers in Verilog HDL, but how > to define a signed number? > I've the following situation: > > reg [7..0] p1 //(is an unsigned value from AD converter) 0..255 > reg [7..0] p2 // is the unsigned value that we should have 0..255 > > now I want to substract p1-p2, to have the differenz, to correct the error > reg[7..0] diff //should be a signed value > > how do I define this in Verilog HDL > > > best regards remo > > > > ----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==---- > http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups > ----= East and West-Coast Server Farms - Total Privacy via Encryption =---- -- / 7\'7 Paulo Dutra (paulo.dutra@xilinx.com) \ \ ` Xilinx hotline@xilinx.com / / 2100 Logic Drive http://www.xilinx.com \_\/.\ San Jose, California 95124-3450 USAArticle: 89207
Symon, I will be sure not to "arsed to explain _again_" anything from you. My point is simply that simulation is key to understanding what is going on. There are no IOs that are any better (or worse) than any others. If internal 100 ohm termination is available, use it. Austin Symon wrote: > All, > Check out the comp.arch.fpga thread entitled "Virtex4 running at 360Mhz DDR" > for a discussion about this stuff. I can't be arsed to explain _again_ that > a 50 ohm line driving 12pF has the same rise time as a 100 ohm pair driving > 6pF. > Paul, IIRC, the Spartan parts you mention don't have on-chip resistive (100 > Ohm) termination, so you need to provide this externally. > HTH, Syms > > "Austin Lesea" <austin@xilinx.com> wrote in message > news:dfn7t6$60a3@cliff.xsj.xilinx.com... > >>All, >> >>The LVDS input is 5 pF + 100 ohms. Differential input is really two >>10pF in series. >> >>So, for highest speed, the differential input is the best. >> >>Austin >> > > >Article: 89208
Subroto Datta wrote: > The two designs are not equivalent; they will create functionally different > hardware, hence the performance difference. The designer is getting tripped > up by a common Verilog gotcha, using a value "1" when he really meant to set > a bit to 1. The problem is this line of test2.v: > {index3, value3} <= {index2, value2 + 1}; > This is *not* equivalent to index3 <= index2; value3 <= value2 + 1. The > constant "1" is treated as a 32-bit wide quantity (as specified in the > Verilog LRM), so "value2 + 1" is a 32-bit quantity. The RHS ends up being 37 > bits wide with the top 5 bits being index2 and the bottom 32 having the > value "value2 + 1". The LHS is only 6+5 = 11 bits wide, so the result of the > assignment is that index3[0] gets the carry bit from value2 + 1, and the > other bits of index[3] become zero. I believe you are right, but last I checked Quartus would give one extra bit for a sum. If value3 and value2 have the same width, value3 <= value2 + 1`b1; should not get the width warning, but it does. -- glenArticle: 89209
Article: 89210
Easy, tiger! No offence intended, I should perhaps have used a less inflammatory turn of phrase. I was merely trying my best to help the OP and was a little exasperated that the same confusing point concerning single ended vs. differential I/O capacitance had arisen once more on C.A.F. So, I see you say in your last post:- "There are no IOs that are any better (or worse) than any others." Yet in your first post in this thread you claim:- "So, for highest speed, the differential input is the best." Now, I gather you will no longer be arsed to explain anything to me, (BTW, many thanks for your help in the past) but would it be possible for you to clarify to Paul, the OP, how he should resolve these apparently contradictory statements? I agree whole-heartedly "that simulation is key to understanding what is going on". I apologise that I failed to realise this was the point you were making in your first post. I also apologise for being a sarcastic bastard. ;-) With tongue firmly in cheek, Syms. "Austin Lesea" <austin@xilinx.com> wrote in message news:dfnrce$3ht4@cliff.xsj.xilinx.com... > Symon, > > I will be sure not to "arsed to explain _again_" anything from you. > > My point is simply that simulation is key to understanding what is going on. > > There are no IOs that are any better (or worse) than any others. > > If internal 100 ohm termination is available, use it. > > Austin > > Symon wrote: > > > All, > > Check out the comp.arch.fpga thread entitled "Virtex4 running at 360Mhz DDR" > > for a discussion about this stuff. I can't be arsed to explain _again_ that > > a 50 ohm line driving 12pF has the same rise time as a 100 ohm pair driving > > 6pF. > > Paul, IIRC, the Spartan parts you mention don't have on-chip resistive (100 > > Ohm) termination, so you need to provide this externally. > > HTH, Syms > > > > "Austin Lesea" <austin@xilinx.com> wrote in message > > news:dfn7t6$60a3@cliff.xsj.xilinx.com... > > > >>All, > >> > >>The LVDS input is 5 pF + 100 ohms. Differential input is really two > >>10pF in series. > >> > >>So, for highest speed, the differential input is the best. > >> > >>Austin > >> > > > > > >Article: 89211
Symon, Our favorite person makes a really big deal out of the 10 pF IO cap number. Only he calls it 12 pF (not sure why .... maybe we have a worst case number somewhere that includes the package C, however the package C is not a bulk C but a t-line, so that C doesn't count). It really is 5pF across 100 ohms, but it sounds better to just continue to pound on 10 pF, as it is confusing enough that some folks will put all 10 pF across the 100 ohms in their simulations. Or worse yet, they will add 10 pF to the IBIS when it is already in the receiver model (single ended) and 5pF differential. As well, "they" use an external 100 ohms for all their simulations, where we recommend use of the internal 100 ohms for all high speed interfaces (really makes things look worse due to the stub). And, to top it off, they claim an open eye at 1.3 Gbs with really fast rise and fall times as a good thing. Well, basically they have to, as they don't have MGTs (in S2), so anything really fast has to look good and distract you long enough to think "hey, maybe they really do have something here?" The fabric can't handle 1.3 Gbs, there is no IP or core for 1.3 Gbs, and the rise and fall is so fast, that passing RFI requirements will be a real trick (should radiate like gangbusters). Really fast rise time more than is needed to support the IO that is designed to be used on a pin or pins is a real waste. You want 1.3 Gbs? Do us and yourself a favor, use the MGTs. Do they have a really fast and clean looking signal at 1.3 Gbs? Sure. If you think that is an advantage without all the other rather useful stuff, then be my guest, and go use it. Good luck. I only fight battles that are worth it, and other than the intentional misdirection every time I see this, I am just ready to say "if you believe this is an advantage, go to it." And, I think you meant "asked" not "arsed." In good fun, Austin Symon wrote: > Easy, tiger! No offence intended, I should perhaps have used a less > inflammatory turn of phrase. I was merely trying my best to help the OP and > was a little exasperated that the same confusing point concerning single > ended vs. differential I/O capacitance had arisen once more on C.A.F. > > So, I see you say in your last post:- > "There are no IOs that are any better (or worse) than any others." > Yet in your first post in this thread you claim:- > "So, for highest speed, the differential input is the best." > > Now, I gather you will no longer be arsed to explain anything to me, (BTW, > many thanks for your help in the past) but would it be possible for you to > clarify to Paul, the OP, how he should resolve these apparently > contradictory statements? > > I agree whole-heartedly "that simulation is key to understanding what is > going on". I apologise that I failed to realise this was the point you were > making in your first post. I also apologise for being a sarcastic bastard. > ;-) > > With tongue firmly in cheek, Syms. > > "Austin Lesea" <austin@xilinx.com> wrote in message > news:dfnrce$3ht4@cliff.xsj.xilinx.com... > >>Symon, >> >>I will be sure not to "arsed to explain _again_" anything from you. >> >>My point is simply that simulation is key to understanding what is going > > on. > >>There are no IOs that are any better (or worse) than any others. >> >>If internal 100 ohm termination is available, use it. >> >>Austin >> >>Symon wrote: >> >> >>>All, >>>Check out the comp.arch.fpga thread entitled "Virtex4 running at 360Mhz > > DDR" > >>>for a discussion about this stuff. I can't be arsed to explain _again_ > > that > >>>a 50 ohm line driving 12pF has the same rise time as a 100 ohm pair > > driving > >>>6pF. >>>Paul, IIRC, the Spartan parts you mention don't have on-chip resistive > > (100 > >>>Ohm) termination, so you need to provide this externally. >>>HTH, Syms >>> >>>"Austin Lesea" <austin@xilinx.com> wrote in message >>>news:dfn7t6$60a3@cliff.xsj.xilinx.com... >>> >>> >>>>All, >>>> >>>>The LVDS input is 5 pF + 100 ohms. Differential input is really two >>>>10pF in series. >>>> >>>>So, for highest speed, the differential input is the best. >>>> >>>>Austin >>>> >>> >>> >>> > >Article: 89212
I wont be able to do the first two methods as it will disable all the output pins. I know that the third method is reasonable. But i am unable to explain the behaviour. 1. I deleted all the connection to the 'A' and 'B' bus from the FPGA. But still some bits in the bus 'B' was missing. Then i connected the FPGA to the bus 'B' and assigned input status. Then bus 'B' started working but bus 'A' reported errors. How can it be possible. The same thing happend when i assigned input to both buses. If i go for bus 'B' bus 'A' gets corrupted and vice versa. If i assign input to both the buses still bus 'A' reported errors. And for your question i dleted all the driving of bus 'A' and 'B' from the RTL. SumeshArticle: 89213
Does anyone know? Please help me! Thank you! LinaArticle: 89214
Can somebody help me wid a PLL generation code with Quartus-2 apex devices... please send me the code for that. it is urgent thanks YaagArticle: 89215
What features of the 2.6 kernel do you require? Just curious... Paul Sven Gowal wrote: > > Unfortunately I have to use the linux 2.6 kernel... but thanks for the > info. > > - SvenArticle: 89216
In article <1126115517.322846.180230@g43g2000cwa.googlegroups.com>, jcarr@linuxmachines.com <jcarr@linuxmachines.com> wrote: >> If I was about to start an FPGA design-in I think I'd be >> seriously looking at Altera right now.... > >If you use linux, then you will probably avoid using windows. Can you >even do Altera development using Linux? Lots of developers using FPGA's >are hobbiests and enthusiasts. Usually that == linux users. Xilinx's >Linux support is excellent. > Well, I don't know about excellent... but it does seem to be getting somewhat better. >That being said, I will admit that although I managed build the >xilinux_pp driver under 2.6.11&13, I can't seem to get the Webpack >version of iMPACT to use it. So, I'm stuck trying to take the Xilinux >created SVF file and use it to program the XCR02S on the S3BOARD via >jtag. It is a shame that Xilinx went so far, did so much great work to >make the webpack run under linux and then didn't spend the >(comparatively small) extra effort to make the xilinx_pp driver work. Isn't this something that's supposed to be coming in a future (hopefully not too far away) version of ISE? PhilArticle: 89217
With Nios II, all EPCS devices are supported, in the manner you mention. With Nios, I'm not sure. With respect to the ST micro device you mention, I'm not sure, though I would suspect that something in the toolchain would fail when accessing the Silicon ID... Here's the basic flow, if using Nios II: 1. Create a target board using the mk_target_board script. - This is where the ASMI component is used (1,4,8,16,64 are pretty much meaningless...) 2. Create an SOPC Builder design referencing this "target board" design. - Be sure to include an epcs_controller component and point the Reset Address to that component. 3. Generate your design. 4. Program in Quartus II. 5. Generate your code in the IDE. 6. Program your code to flash. - Your "EPCS" device should be the only choice. - If you have a Silicon ID problem, this would be where you'd see it. 7. If successful, then just power cycle your board and it should come up running your code from step 5. Cheers, - BrendanArticle: 89218
"Simon Peacock" <simon$actrix.co.nz> wrote in message news:431ebdbc@news2.actrix.gen.nz... > almost right > 01101 /= -3 > 11101 = -3 > > you need to sign extend ;-) > > Simon > Surely not for the example given. The fifth bit there was the carry bit from a 4 bit operation. Thus the answer only takes 4 bits and is correct. The carry bit is used for error detection. If the carry into the MSB and the carry out of it are different, the 2's complement operation has overflowed. The overflow bit in a processor is just the result of an exclusive or on the two carries. Pete Harrison Sylvain's original sums: >> Signed and unsigned addition are the same. Their results is to be >> interpreted differently though ... >> >> Let's says the number are 4 bits unsigned : >> >> 1001 = 9 >> 0100 = 4 >> -------- >> 01101 = 13 >> >> now if they are 4 signed : >> 1001 = -7 >> 0100 = 4 >> --------- >> 01101 = -3 >> >>Article: 89219
Actually, I could use Linux 2.4 but it would ask me to make all my char drivers compatible with it. Since they changed a lot of stuff for module compiling, loading, ... it would be too much work. SvenArticle: 89220
Hi, I developed PCI board with xilinx prom & fpga on it. Since PCI has jtag pins and since the prom xcf16p is programmed through its jtag interfacce, I wonder if there is a known application software to burn the xilinx prom & devices through PCI jtag interface ? THANKX NAHUMArticle: 89221
Lina wrote: > Does anyone know? Please help me! > > Thank you! > > Lina Lina, I've used Memec's DS-KIT_2VP4LC product. I got it to boot from Flash on an old style P160. The newer ones are a bit different. I also got it to work booting from an ACE-CF. That was a bit more of a challenge. I had to rework the ACE connector to fit with their ACE-CF module. Had to fiddle with formatting the drive and put debug code in the driver to attain visibility to debug the interface. The Flash interface was much easier to get going. -NewmanArticle: 89222
Hi All, I am developing a board using XC2VP20-6FF1152 with a 184 ddr pc3200. The documentation (Scheamtics and gerber/pdf) of xilinx ML361 board would be very healpful. Can anyone send it to me?? Tanks AllArticle: 89223
?Article: 89224
Hi, > I am developing a board using XC2VP20-6FF1152 with a 184 ddr pc3200. > The documentation (Scheamtics and gerber/pdf) of xilinx ML361 board > would be very healpful. Can anyone send it to me?? The user guide and schematics are available here: http://www.xilinx.com/bvdocs/userguides/ug060.pdf (user guide) http://www.xilinx.com/bvdocs/userguides/ug060.zip (schematics) The Gerbers should be on the CD which came with the board. -Ben-
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