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
Jerry Coffin wrote: > > It looks like their RaggedStone1 board should let you use > 28 LVDS pairs quite easily. They indicate that they've > routed the traces to minimize skew on those pairs too. > I think that's a Spartan3 board, not a 3E Also, the RaggedStone1 headers have 60 pins, one power, one ground If everything's perfectly balanced, that pinout might be OK with low speed differential drivers, but I wouldn't try running any 640 Mbps data through it. BrianArticle: 97826
You have to start a new project (or open an existing one) before it shows you the IP. Barry <foag@iti.uni-luebeck.de> wrote in message news:1140979534.650678.134920@i40g2000cwc.googlegroups.com... Hello, after starting Coregen 6.1i, no IP core is sohwn although I have done Get models under the Tools button. Do I have to set another PATH variable or anything similar ? Thanks for any ideas JürgenArticle: 97827
Hallo, how much clock cycles takes a conv_integer operation? Many Thanks MarcoArticle: 97828
There must be some error message.Can you display them?Article: 97829
You cannot calculate with "clock cycles" when using conversion functions. Conversion functions and the corresponding data formats are dissolved by the synthesis tool during synthesis process so that in the end (real hardware) everything is implemented in std_logic/std_logic_vector. Use "to_integer" with library "ieee.numeric_std.all" instead of conv_integer. Rgds Andr=E9 > Hallo, > how much clock cycles takes a conv_integer operation? >=20 > Many Thanks > MarcoArticle: 97830
Benjamin Todd wrote: > Jim's right, > > CPLDs are power hungry... 300-400mA is no problem for bigger ones, there's > an equation to work it out somewhere... From > http://direct.xilinx.com/bvdocs/publications/DS066.pdf > > You have ICC (mA) = MCHP (1.7) + MCLP (0.9) + MC (0.006 mA/MHz) f > > say the valid range is 180 - 250 mA for high performance Then you have to > look at the package thermal characteristics for the package you use, > (PLCC-84 / PQFP-100 / TQFP -100 / PQFP - 160) In the document > http://www.xilinx.com/bvdocs/userguides/ug112.pdf to calculate the external > temperature. > > I have some 95288 devices that run at 40-50 degrees, which is backed up by > these equations. Note that your finger is quite a good thermometer, if it > feels warm, its probably 40-50 degrees, if its not possible to touch for a > prolonged period it closer to ~60, and if you simply cant touch it it's ~70, > if you look at your finger and see XC95108 burned in it... then it's hotter > still =) It's the other way round - fingerprint burnt into the plastic! I once put a finger on a chip that had been inserted into the socket the wrong way round, so I know from experience. 8-( The chip actually worked when it was inserted correctly, to my surprise. LeonArticle: 97831
<ALuPin@web.de> wrote in message news:1141139496.282536.280520@z34g2000cwc.googlegroups.com... You cannot calculate with "clock cycles" when using conversion functions. Conversion functions and the corresponding data formats are dissolved by the synthesis tool during synthesis process so that in the end (real hardware) everything is implemented in std_logic/std_logic_vector. Use "to_integer" with library "ieee.numeric_std.all" instead of conv_integer. Rgds André > Hallo, > how much clock cycles takes a conv_integer operation? > > Many Thanks > Marco What is the difference between "to_integer" and "conv_integer"?Article: 97832
> What is the difference between "to_integer" and "conv_integer"? they are from different libraries ... you should use numeric_std, you should *not* use std_logic_unsigned or std_logic_signed, for reasons see: http://www.vhdl.org/comp.lang.vhdl/FAQ1.html overview of conversion functions: http://dz.ee.ethz.ch/support/ic/vhdl/vhdlsources.en.html tricks and examples of the numerics: http://www.synthworks.com/papers/vhdl_math_tricks_mapld_2003.pdf bye, MichaelArticle: 97833
Eric Smith schrieb: > Jim Granville <no.spam@designtools.co.nz> writes: > >>That's a large array - does it really cover 2^25 combinations, >>or can you compress the inputs, so that the remainder can fit into >>Block Ram(s) ? > There are lots of don't cares scattered throughout the > AND matrix of the PLA, > [...] > I might try having hacking my Python tool that translates the PLA > so that it directly instantiates trees of four-input gates for all > of the product terms and sum terms, with a "keep" attribute on each > gate output, and see what kind of timing that gets me. Make sure to translate the don't cares to your VHDL and to use a synthesis tool that makes use of the don't cares. AFAIK ISE just set's all specified don't cares to '0'. I can also imagine that most tools are not well tuned to syntesize large sop descriptions. You can try to feed the design through some university synthesis tool first. See what SIS makes out of it. Or try a BDD package. A BDD package will generate at most 25 levels of logic for that design. Probably a lot less. Generate VHDL from the BDD and feed that to ISE, maybe it does a better job optimizing that instead of the SOP description. If there are any outputs that depend on less than 14 inputs push those into BlockRAMs. Kolja SulimmaArticle: 97834
Setting up MicroBlaze-uClinux on new FPGA board is a matter of hours - with PPC linux, well there are gurus around claiming that it can be done within 4 hours - so far I have been very sceptical against such claims mainly as I had until 10 minutes ago never created a Xilinx FPGA PPC system with linux booting capability So my schedule was 1 New V4 PPC system with EDK (complete from scratch) 2 ppc u-boot, compile test working 3 ppc uClinux, build load run, console prompt ================== => 2.5 days work that is a defenetly more than 4 hours, but hey I believe now that some guy with extensive linux-ppc-fpga experience could have managed it all in 4 hours. First time try til succesful linux prompt its just me who needed a bit more :) When its done it always simple, the PPC capable linux SoC requirements are actually same as for the microblaze uclinux ram, intc, timer, uart, then load linux.bin start and you get console prompt! so my way to working PPC (uc)linux (with MMU !) was 1 VMWARE player, KDE 3.5/SUSE 2 http://www.itee.uq.edu.au/~pml/uclinux_powerpc/ 3 build 4 WinXP, EDK 8.1 SP1, BSB new design, add uart, timer, plb sdram 5 configure, start bootloader, 6 wath the uclinux to boot up I had to run synthesis maybe 8 or 9 times to get 'linux-ready' bitstream, and I spend lots of time trouble shooting the kernel as I used old version (make copied the new kernel to tftboot not to tftpboot from where I fetched it...) jipii jeee!!! Antti PS at the same clock frequency the V4 PPC design seems to use less power (V4FX12-363 is not warm at all!) then similar microblaze design in the same deviceArticle: 97835
young schrieb: > There must be some error message.Can you display them? Actually there is none. Just "XST failed".Article: 97836
For some applications 2 Srams can be used in an alternate buffer configuration. I assume your 2 ports have similar issue rates otherwise you may have to mux in time.Article: 97837
Marco This is only a VHDL function defined in a library. Effectively it in itself is instant. Your speed, frequency, or number of clocks will be determined by the functions arround it and how data is used. John Adair Enterpoint Ltd. - Home of Raggesdtone1. The $90 Spartan-3 Development Board. http://www.enterpoint.co.uk "Marco T." <marc@blabla.com> wrote in message news:du1or7$6fp$1@nnrp.ngi.it... > Hallo, > how much clock cycles takes a conv_integer operation? > > Many Thanks > Marco >Article: 97838
In article <1141137569.344605.223290
@j33g2000cwa.googlegroups.com>, brimdavis@aol.com says...
[ ... ]
> I think that's a Spartan3 board, not a 3E
Yes, that's correct. At least according to Xilinx, the
basic difference between 3 and 3E is that the former
emphasizes I/O while the latter emphasizes gates. As
such, insisting that something be 3E based, but then
complaining that only big/expensive ones have as many
I/Os as you want doesn't seem to make a lot of sense.
> Also, the RaggedStone1 headers have 60 pins, one power, one ground
>
> If everything's perfectly balanced, that pinout might be OK with
> low speed differential drivers, but I wouldn't try running any 640 Mbps
> data through it.
You've mentioned better grounding in another post, so
presumably that's what you see as being wrong here. Given
that this is differential signalling, I'm not sure how
the number of ground pins would mean much though. When
you're doing single-ended signalling, you use lots of
ground pins to maintain a stable ground plane, and you
need to do that because your signal wires are referenced
to ground. With differential signalling, the ground is
necessary to complete the circuit, but the signals are
referenced to each other, not to ground.
--
Later,
Jerry.
The universe is a figment of its own imagination.
Article: 97839Hello, on the "Digilent XUP Vertex-II" the J5 and J6 connectors (Low Speed Extension Connectors) run with 2.5V, although I used for the IO-type "LVTTL" in the UCF-File. Is it impossible to run these connectors with 3.3V or does anyone know what my problem could be? My board: XUP Vertex II Pro Development System FPGA: XC2vP30, ff896 thank you for help Ludwig LenzArticle: 97840
Frank, you posted this in the FPGA newsgroup. In FPGAs, most RAM structures are naturally dual-ported, e.g. the Virtex BlockRAMs. You get two ports, whether you asked for it or not! Peter Alfke, Xilinx Applications. Frank @ CN wrote: > Hi, there: > > In my application, a RAM needs to be written/read from two sets of > data/address ports > simultaneously. However, in the ASIC library I can only instantiate some > single port RAM > and RAM which can be written in one port and read from the other port. > > How shall I solve this problem? > > Thank you.Article: 97841
Peter Alfke wrote: > Ray, with all due respect: > Yes, this problem was first found by a couple of customers, and you > were probably the first. But only we at Xilinx know the innards of the > control logic implementation, and I was the one that clearly traced the > problem to the inputs of two internal flip-flops. Having analyzed it, I > can assure you that there is nothing mysterious about the misbehavior. > It happens very rarely, but always for an identifyable logic reason. It > has nothing to do with metastability, it is totally deterministic. The > description may sound convoluted, but the behavior is clear. It has to > do with the ALMOST EMPTY flag potentially getting and staying > inverted. And since ALMOST EMPTY is used as a necessary condition for > decoding EMPTY, the EMPTY flag also gets impacted, if, AND ONLY IF, > there is a simultaneous read/write operation on the second clock tick > AFTER REACHING OR LEAVING THE THRESHOLD OF "ALMOST EMPTY". > That's why the failure occurs so rarely in an asynchronous FIFO use. > If ALMOST EMPTY stays active,( i.e. if its deactivating threshold is > set high enough to never be reached) there will never ever be an > erroneous EMPTY flag. > We have analyzed this, and then also simulated and tested it, and > provoked it. > I know all the gory details. That's why I gave Brad this strong > assurance that in his design he can 100% rely on the EMPTY flag going > active when it should, and going inactive soon after something has been > written into the FIFO16. > I have had sleepless nights over this. Brad does not have to... > Peter Alfke, from home > Peter, I didn't go back and revisit the design afterwards. At the time I was debugging this, we didn't know that the issue was with the almost empty flag, and since I was not using it I didn't look at it at all. I don't think the FIFO should have ever gotten full enough in the design to cause the almost empty to change state, but it is possible either it was getting filled up more than I thought during the start-up sequence due to the test fixture, or that the almost empty depth attribute was still at the default of 4. Since I didn't have the benefit of Xilinx's description of the problem, I didn't know to look at the almost empty and didn't consider it at all in the debug effort (my design doesn't use it). Brad, make sure you set the almost empty threshold high enough that you will *never* hit it if you use it as Peter suggests.Article: 97842
In news:nn1kv1t60lgcsm0tn2v5tnhnbn836166ed@4ax.com timestamped 23 Feb 2006 12:39:58 -0800, it was posted "[..] The Google description for this group is: Field Programmable Gate Array based computing systems, [..] [..]" In news:468449F9vf44U1@individual.net timestamped Fri, 24 Feb 2006 10:06:01 -0000, Nial Stewart replied: "[..] This newsgroup and FPGAs were around long before some numpty at Google decided what their description should be. [..] [..]" This has nothing to do with Google. Check your newsgroups file, the description of this group is "Field Programmable Gate Array based computing systems." See WWW.SLRN.org/manual/slrn-manual-6.html#ss6.117 or HTTP://Quimby.Gnus.org/gnus/manual/gnus_358.html#SEC358 or something similar.Article: 97843
Eric Smith wrote: > I have a design with a large PLA, and I'm trying to make it run fast in > a Spartan-3. It's too big for block RAM, since it has 25 inputs, > slightly fewer than 512 product terms, and 32 outputs. > > My first attempt was to just translate the PLA equations to VHDL and > synthesize it with the default settings. This uses 34% of a 3S500E, and > has a minimum cycle time of slightly under 12 ns with over 20 levels of > logic. If I turned on timing-directed mapping, or increased the effort > levels, I suppose it might get slightly better. But my own analysis > suggests that it should be possible to implement the PLA with no more > than 11 levels of logic worst case, seven levels for the product terms, > and 4 levels for the sums. My analysis suggests 3+5=8 as the minimum number of levels of 4-input luts: 4*4*4=64> 25 and 4*4*4*4*4=1024> 512. A product could require up to 8 luts, a sum up to (2**9+1)/3=171 for a total of 512*8 + 32*(2**9+1)/3=9568 luts. What am I missing?Article: 97844
Jerry Coffin wrote: > > As such, insisting that something be 3E based, but then > complaining that only big/expensive ones have as many > I/Os as you want doesn't seem to make a lot of sense. > It makes perfect sense that someone looking to test the new Spartan-3E I/O's would want to use a S3E, not an S3 Spartan-3E's have internal _DT terminators; Spartan-3's don't Page 54 of the following also notes significant improvements in the I/O driver structure http://www.xilinx.com/products/spartan3e/sp3e_power.pdf > You've mentioned better grounding in another post, so > presumably that's what you see as being wrong here. My specific complaint was that many of the expansion connectors, even on the vendor-sponsored eval boards, remain frighteningly sparse of grounds, well into the era of sub-ns I/O speeds. When a few cents more to add a row of ground pins, route the I/O lines over a continuous ground plane, and not share the "high speed" I/O lines with on-board LEDs and such would be quite simple to implement. >With differential signalling, the ground is necessary to >complete the circuit, but the signals are referenced to >each other, not to ground. If the signals were perfectly balanced and the PCB pairs 100% coupled entirely to each other rather than the ground plane, you could live with a ground-free I/O connector. In practice, with real world PCB routes and drivers, maintaining ground return continuity through the expansion connector is important even for differential signalling at high speeds. There was a nice thread on this over here: http://groups.google.com/group/comp.arch.fpga/msg/40f5f32e8f176132 BrianArticle: 97845
I wrote: > > Also, the RaggedStone1 headers have 60 pins, one power, one ground > One thing I missed on the first read of the RaggedStone1 manual, is that seven pins of the middle LHS connector row can be selectively jumper grounded; this would let you get 3-4 LVDS pairs with nearby grounds. Another nice provision is for DCI on the I/O banks, so you can use the various DCI terminations with the I/O connectors. Maybe a future S3E board will have a G+-G connector pinout :) BrianArticle: 97846
Thanks I'm going to read taht right away ;-) Benjamin Todd wrote: > I agree, > > check Xilinx Application Note 73 > http://direct.xilinx.com/bvdocs/appnotes/xapp073.pdf > > One of the last pages outlines the good approaches for decoupling. > > Ben > > "PeteS" <ps@fleetwoodmobile.com> wrote in message > news:1141118118.178506.30000@p10g2000cwp.googlegroups.com... > >>:-) wrote: >> >>>Hey ! >>> >>>Cool everything fit into my XC9572 and work like a charm :-) >>> >>>Now should I used some decoupling for the xc9572, I/O change at low >>>freq (around 2kHz ). >>> >>>My question is how and how much ;-) >>> >>>:-) >> >>If you aren't switching a huge number of outputs, one 0.01uF or 0.1uF >>cap per power pin (there are three) and a single bulk cap of about 1uF >>should be perfectly adequate. I use that on a device connected to an >>AC97 chain (clock at 12.288MHz, outbound stream at 256kb/s) and it >>works just fine. >> >>Cheers >> >>PeteS >> > > >Article: 97847
if you dont tel what your problem is how can anyone help? IO cells powered with 2.5V can not drive aboe 2.5 and have limited input voltage tolerance compared to 3.3v powered IO but you can probably use LVTTL 3.3V iostandard even if bank vccio is set to 2.5, but that depends on the applicationArticle: 97848
Hi Antti, currently, you are the uCLinux guru in FPGA SoC ;) Do you publish your work on the web? I think it could be useful for a lot of people. Particularly, the PowerPC-uCLinux implementation is interesting for me. I have implemented some PowerPC systems, but I have never time to run uCLinux in PowerPC. And, are you trying Linux? Good work. Regards, Ivan Antti wrote: > Setting up MicroBlaze-uClinux on new FPGA board is a matter of hours - > with PPC linux, well there are gurus around claiming that it can be > done > within 4 hours - so far I have been very sceptical against such claims > mainly as I had until 10 minutes ago never created a Xilinx FPGA PPC > system with linux booting capability > > So my schedule was > > 1 New V4 PPC system with EDK (complete from scratch) > 2 ppc u-boot, compile test working > 3 ppc uClinux, build load run, console prompt > ================== > => 2.5 days work > > that is a defenetly more than 4 hours, but hey I believe > now that some guy with extensive linux-ppc-fpga experience > could have managed it all in 4 hours. First time try til > succesful linux prompt its just me who needed a bit more :) > > When its done it always simple, the PPC capable linux SoC > requirements are actually same as for the microblaze uclinux > ram, intc, timer, uart, > then load linux.bin start and you get console prompt! > > so my way to working PPC (uc)linux (with MMU !) was > > 1 VMWARE player, KDE 3.5/SUSE > 2 http://www.itee.uq.edu.au/~pml/uclinux_powerpc/ > 3 build > 4 WinXP, EDK 8.1 SP1, BSB new design, add uart, timer, plb sdram > 5 configure, start bootloader, > 6 wath the uclinux to boot up > > I had to run synthesis maybe 8 or 9 times to get 'linux-ready' > bitstream, and I spend lots of time trouble shooting the kernel > as I used old version (make copied the new kernel to tftboot > not to tftpboot from where I fetched it...) > > jipii jeee!!! > > Antti > PS at the same clock frequency the V4 PPC design seems to > use less power (V4FX12-363 is not warm at all!) then similar > microblaze design in the same device >Article: 97849
"Ivan" <gmivan@terra.es> schrieb im Newsbeitrag news:HA2Nf.665634$kp.4685064@telenews.teleline.es... > Hi Antti, > > currently, you are the uCLinux guru in FPGA SoC ;) > > Do you publish your work on the web? I think it could be useful for a lot > of people. Particularly, the PowerPC-uCLinux implementation is interesting > for me. I have implemented some PowerPC systems, but I have never time to > run uCLinux in PowerPC. And, are you trying Linux? > > Good work. > > Regards, Hi Ivan, the trick is there is no trick, its just is plain and simple ! compile the uclinux kernel as described here http://www.itee.uq.edu.au/~pml/uclinux_powerpc/ I used the same ref design that was included in that distro, only changing the amount of memory from 128MB down to 16MB after that created a ppc refdesing that matches the autoconfig loaded the linux image at 0x400000 into ram and executed it will decompress itself and boot. really no tricks - but as I had not done that before I was afraid it is more complicated, when in the matter of fact it isnt. I was trying to boot up the PPC SoC step by step 1) bram + uart, test for 'hello' 2) adding GPIO connected Sd-card (for image bootloader) 3) adding PLB sdram, testing with u-boot 4) adding intc, timer, testing with uclinux I think the same system can run full linux as well, because the ppc uclinux actually is using MMU already so it is almost full linux, I was using ppc uclinux as next step simply because of previous experience with Microblaze uclinux. And yes there will be some contributios back from me sd card drivers for u-boot,uclinux, some other stuff maybe as well, but well I need to get the source code cleaned up etc.. Sure I will check out the ppclinux 2.6 also, just next step.. Antti
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