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
Please contact support.xilinx.com and start a webcaseArticle: 97751
This might be a dumb question, but I can't seem to find it in the Xilinx documentation anywhere. I'm using a VirtexII (XC2V2000) FPGA for my university project, and can't find out how wide the various interconnects between the logic blocks are (i.e. single bit, 4-bit, or larger). I understand the hierarchy of it, just not how wide they are... anyone got any clues on where I can find this out? The lines I'm looking at are: Long lines Hex lines Double lines Direct connect lines Thanks in advance, and any help is very much appreciated! ChrisArticle: 97752
all lines are 'single' line :) the best info is to look with FPGA editor or then XDL fileArticle: 97753
Martin Schoeberl wrote: >> i plan on synthesizing miniuart (opencores.org) onto a spartan 3 demo >> board. but then i dont know how to test it. how do i configure/run a >> terminal console in windows to talk with my board? >> > Hyperterminal ? > No, not Hyperterminal. Use pretty much anything except Hyperterminal - from wide experience (personal and heresay - this crops up in comp.arch.embedded regularly), Hyperterminal is often very unreliable as well as being overly complicated for a direct RS-232 connection. You are far better downloading Tera Term Pro (first hit on google). It is much better suited for connecting embedded boards to a PC. If you want something a bit more powerful, with easy control of the control lines, display in hex, and that sort of thing, at a cost of a more complex interface, go for RealTerm. Both programs are free and open source.Article: 97754
>> That's probably true, and I expect to be using other tools as well as >> VHDL in 5 years. However as John posted above, there's alot more to >> implementing an FPGA design than the description used for the logic >> and I think we'll still be using HDLs to get the most out of them for >> a long time to come (to a bigger extent than with C/asm). > > Probably the biggest change is that EE's will still be putting the > chips on boards as they have always done, and the FPGA programming will > shift to systems programming staff, which are frequently Computer > Engineering folks these days (1/2 EE and 1/2 CSc, or CSc types with a > minor in the digital side of EE). That may be the case for large multi designer designs, for smaller devices someone who understands the underlying architecture and what they're actually trying to design to will be needed. This is a quote from a current thread "Entering the embedded world... help?" on comp.arch.embedded. I don't know how accurate this is. "If you meant to say "most everyone these days uses an HLL, and for embedded applications most people choose to use C whereas a significant minority choose to use C++" I would not have objected much - although, in terms of code volume on the shelf, assembly language is still at least 30% of all products. Consider that the really high-volume projects use the really cheap micros. I've seen numbers that say asm 40%, C 40%, C++ 10%, other 10%, and I'm quite prepared to believe them. The problem is, people who talk about this stuff get into their niche and see everything else from that perspective. Few people routinely work with a broad spectrum of systems from 4-bit to 64-bit and code volumes from a few hundred bytes to a few dozen megabytes." You seem to have a deeply entrenched view of the FPGA development future. Only time will tell if you are correct or not, I don't believe you are and I'll leave it at that. Nial.Article: 97755
Antti wrote: > all lines are 'single' line :) > the best info is to look with FPGA editor or then XDL file Cheers!Article: 97756
Augast15 wrote: > hi, > There is 4.5 V supply for entire circuit throughout the board. > > I am testing with schmitt trigger today > thanx guies > Augast15 You can actually use a Schmitt gate as an oscillator. That is what Xilinx did on one of their little CPLD evaluation boards. Just takes a 390 ohm resistor and capacitor. LeonArticle: 97757
Eric First comment is that you have a lot of levels of logic. Might not be a problem if only carry logic. Is the 12nS a result of the a build with a timing constraint set or run without? Often you can assist speed by seperating logic manually into logical blocks and not allowing the synthesis process to share logic. Sometimes you can enforce a function crudly by using the negative edge to produce a sub-term but that does not always work well. If you set the frequency constraint to what you want the tools will usually give a failure if there is no chance of making timing. The thing then is examine where you fail and see if you can pipeline or in some way make it faster. One thing to remember in SRAM based FPGAs is the the width, or number of inputs, to a function have a direct significance on the levels of logic and hence speed. So as an example if you have a state machine driving this logic consider using grey or binary encoding rather than the usual default of one-hot if it is such an input. John Adair Enterpoint Ltd. - Home of Hollybush1. The PC104+ FPGA Development Board. http://www.enterpoint.co.uk "Eric Smith" <eric@brouhaha.com> wrote in message news:qh4q2lcjgi.fsf@ruckus.brouhaha.com... >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. > > Anyhow, as the subject line suggests, I'm interested in any clever > tricks to get more efficient FPGA implementation of the PLA. For > instance, would use of the carry chain speed up wide gates? (Or do > the tools already infer that?) Should I put some constraint on the > product terms, to keep the tools from merging the product term and > sum logic? > > I'll experiment with this myself, but perhaps someone here has already > done this, in which case suggestions would be quite welcome. > > Thanks, > EricArticle: 97758
Hi, I have written a presentation about my PhD. Thesis work. My final application was a hardware-accelerated SSH version over a MicroBlaze-uCLinux Self-reconfigurable system based on Spartan-3 FPGA. On it, all information about partial reconfiguration is shown. I think it can be useful for you. I had to resolve the lack of the ICAP module (Spartan-3 has not ICAP, so I used a external circuit) and a lot of problems related with partial reconfiguration (I developed a custom tool that was successfully tested in Spartan-3, Virtex-E and Virtex-II). Of course, I hope that future ISE versions resolve the problems :) Link: http://www.ii.uam.es/~igonzale/recursos/Self_Reconfigurable_Coprocessors.pdf Regards, Ivan Antti Lukats wrote: > "pablo" <sec_lab@libero.it> schrieb im Newsbeitrag > news:1140966379.138525.199430@i40g2000cwc.googlegroups.com... >> Stephen Craven ha scritto: >> >>> Any board out there with a Virtex-II, Virtex-II Pro, or Virtex-4 will >>> support run-time reconfiguration through the Internal Configuration >>> Access Port (ICAP). ucLinux can be easily run on a MicroBlaze on any >>> of these boards and Monta Vista Linux is available on the PPC on many >>> 2vp boards. >>> >>> As for a board that has reference designs supporting partial dynamic >>> reconfiguration, I know of none that exist. Partial reconfiguration is >>> not an easy task and, as several other posts will contest to, it is >>> currently broken in the tools. >>> >> >> My question then is... >> what do I do with the ICAP component if partial reconfiguration (and >> thus, in particular, self-configuration, which is partial and dynamic >> by definition) is not supported by the development tools???? >> >> Or, do ICAP-based self-configuring designs actually exist out there? >> If this is the case, how could I find some examples? >> >> Many thanks again >> pablo >> >> >>> I have heard that Xilinx is working on the problem, as there is growing >>> demand for this from the Software Defined Radio community. >>> >>> Stephen > > nomans land, no examples, possible by theory only. > if you want then its a lot of hard work on pain. > > sure it depends what you want todo, implementing small changes > isnt a problem, just look the locations in the .LL file and rewrite using > ICAP > but if you want to reload larger part of the FPGA then it comes a major > problem > > Antti > > > > > >Article: 97759
On 27 Feb 2006 00:08:29 -0800, Eric Smith <eric@brouhaha.com> 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. Have you tried simply comparing "optimize for area" versus "optimize for delay" settings in the synthesis tool? That can make a big difference, at least with Leonardo Spectrum; you don't say which synth tool you are using. - BrianArticle: 97760
fpga_toys@yahoo.com schrieb: > Peter Alfke wrote: > >>That then also means ball grid arrays, and is great for professional >>assembly, but a killer for the hobbyist. > > > The funny thing is that BGA brings SMT to the hobbiest, where high > density flat packs have a pitch so narrow that parts can not be hand > placed on paste, or easily soldered by hand, even with a stereo > microscope that easily, but possible for smaller pin count devices like > memory. > > I've shown that home brew computer group here how to reliably solder > BGAs, and reball them, so they can use salvage at low cost. Placing and > soldering a 400-700 ball bga is a piece of cake, hand soldering the > SDRAM and EEPROMS for the design is REALLY painful for TSOP's. Naaa. Some yeas ago I did my own Spartan-II demoboard, using a TQ144 package with 0.5 mm pitch. It was not so difficult. OK, you need some training and the right solder iron, but after a while if will be no big deal. > It's actually easier to do powerful hobby designs in BGA, than it was > in dip parts. I wouldnt agree. DIP is still easier to handle, but sure, if you want to achive a given functionality, a BGA device this tons of power inside can easy replace a bunch of standard euro cards filled with leagacy DIP stuff. Regards Falk >Article: 97761
Jerzy Gbur wrote: > Austin Lesea napisa=B3(a): > > Have you considered the immediate cost savings and no risk that you > > would gain with EasyPath? > > > > http://www.xilinx.com/products/silicon_solutions/fpgas/easypath/ > > Thank you, Austin and Gabor. Easy path looks very interesting for my > use, but I've nowhere found information about power consumption of this > solutions. It is very important this dice to be less hungry for power, > then equivalent FPGA. > > Kind regards > > Jerzy Gbur EasyPath does not affect the power, because you're actually getting the same FPGA you started with. Cost savings come from reduced test requirements (i.e. the part is only guaranteed to work with your design, not all possible designs).Article: 97762
Jerry Coffin <jcoffin@taeus.com> writes:
|> > Does any of you knows where can I obtain the VGA specification (I
|> > believes it is IBM's) ?
|>
|> For quite a while now, most video standards have been
|> handled by VESA. To support plain-Jane VGA, they have a
|> set of "fallback" timings to run a monitor at 640x480 or
|> 720x480 at:
|>
|> http://www.vesa.org/Public/SMT/SMT640_720x480V1.pdf
|>
|> If you want to support other resolutions, they have a
|> spreadsheet at:
|>
|> http://www.vesa.org/Public/CVT/CVTd6r1.xls
|>
|> that allows you to enter resolution, refresh rate, etc.,
|> and it calculates timing parameters for you (and verifies
|> whether what you're asking for will be supported by a
|> typical display).
The official VESA list of video timings is a document called
Monitor Timing Specifications -- VESA and Industry Standards
and Guidelines for Computer Display Monitor Timing, Version 1.0,
Revision 0.8, September 17, 1998, dmtv1r08.pdf.
(That's the version I have a copy of, there may well be newer versions.)
Sadly, that seems not to be freely available on the VESA web site.
You may have to order and pay for it.
The DMT standard is in the same format at the SMT document above,
but contains a pretty complete list of all the commonly used VGA
timings. The SMT is basically a 2-page extract of the full DMT list.
What the DMT document does not contain is the electrical and mechanical
specifications for the VGA connector. There seems to be no formal
standard; in fact there seems to be not even strong agreement on
whether full white is represented by 0.7 V ("Euro", VESA),
0.714 V (RS-343) or 1.0 V (RS-170). VESA has AFAIK never fully
formally standardized IBM's 15-pin VGA connector. General wisdom
appears that the RGB lines are 75 ohm impedance, while the sync lines
are TTL (on > 2.4 V, off < 0.5 V at driver, >2.0 V and < 0.8 V at
receiver) with 2 kiloohm termination.
Markus
--
Markus Kuhn, Computer Laboratory, University of Cambridge
http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
Article: 97763On a sunny day (26 Feb 2006 15:33:20 -0800) it happened "Isaac Bosompem" <x86asm@gmail.com> wrote in <1140996800.146251.277360@e56g2000cwe.googlegroups.com>: > >For myself, I hand-built a Z80 SBC about 2 yrs ago, it still works >today :) : >I clocked the CPU @ 2.45Mhz (same clock into USART), have 2KB of flash >and 32KB of RAM and a single 8-bit output port. It is a nice >development system. I wrote some IEEE754 FP library in Z80 assembly. It >was relatively painless since I am fairly comfortable with the x86 and >scores other CPU's instruction set. Hey, Z80 cool. I build a Z80 system in the eighties, needed an OS too, so I wrote a CP/M emulator for it, disassembler, practically any application soft you can think of, has even audio audio editor, and then wrote a multitasking kernel for the z80 that ran text windows and mouse... then the 64 kByte was full. http://panteltje.com/panteltje/z80/index.html diagrams are there too, the thing is in the attic, 2 euro card backplanes with CPU, IO (EPROM programmer), serial IO, DRAM RAM disk, VDU, more, cannot remember.... lots of plug-in Euro cards. But honestly I would not want to go back to Z80 today. Should take some pictures some day, probably the EPROMS are duff by now... For 1 M$ you can buy it and the rights to the CP/M emulator for embedded ;-) However the multitasker is still on 5 inch flop, and I have no way these days to make a copy.. That dz80 disassembler was actually one of my first C programs, and it shows.... People seem to be using it though.Article: 97764
One thing to watch out for if you have many inputs and rely on clamp diodes: When the inputs are high they can raise your 3.3v VCCO to unsave levels unless you have a large load on VCCO. Voltage regulators normally work only one way (they supply current)... Peter WallaceArticle: 97765
Because of comments from others on this forum, I've gotten into the habit of LOCing the BlockRAMs whenever relative placement is critical. While there might be a slightly "better" location for the BlockRAMs than what I choose, the place & route seems to do a better job filling the logic around the memory rather than trying to figure out a good placement for both logic and memory at the same time. "sudheer" <ksudheerkumar@gmail.com> wrote in message news:1141033138.838815.238520@v46g2000cwv.googlegroups.com... > XST is synthesising the following verilog code to a 8192x24-bit RAM. > <code snipped> > > ISE is mapping this 8192x24bit RAM to 12 RAMB16s. But when the device > is occupying about 65% resources (with other modules integrated) the > RAMs are not placed as neighbors leading to different timing problems > on different compilations. > > The requirement is to allow the ISE-map to place these RAMs closely, > either in a column or controlled rectangular array of RAMB16s, after > which PAR can place this group optimally anywhere in FPGA based on > other modules. > > I am not able to use RLOC or RLOC_RANGE constraints to accomplish this. > Kindly let me know how to control the relative placement of RAMB16s. > > Thank you and I await your inputs/ suggestions ASAP. > K Sudheer KumarArticle: 97766
bijoy wrote: > Hi I have made a generic component like below > > entity fifo is generic( AW : integer; PROG_EMPTY_THD : > std_logic_vector(AW downto 0);... The problem is that you are using AW within the generic declaration area. The way you are doing that is a bit unusual too. Make PROG_EMPTY_THD a signal instead of a generic, and the problem should go away.Article: 97767
I kind of came late to this party but you might be interested in the TI datasheet (if you can find it) of the 74ACT8867. It was a high speed math processor. Four of them were used in the GE6, geometry engine of SGI VGX graphics system (pre-Reality Engine). If you can find the data sheet or anybody has it, I'd appreciate it if you would share it with me. DerekArticle: 97768
Duane Clark wrote: > bijoy wrote: >> Hi I have made a generic component like below >> >> entity fifo is generic( AW : integer; PROG_EMPTY_THD : >> std_logic_vector(AW downto 0);... > > The problem is that you are using AW within the generic declaration > area. The way you are doing that is a bit unusual too. Make > PROG_EMPTY_THD a signal instead of a generic, and the problem should go > away. Oops, and of course also PROG_FULL_THD.Article: 97769
"Eric Smith" <eric@brouhaha.com> wrote in message news:qh4q2lcjgi.fsf@ruckus.brouhaha.com... >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. > > Anyhow, as the subject line suggests, I'm interested in any clever > tricks to get more efficient FPGA implementation of the PLA. For > instance, would use of the carry chain speed up wide gates? (Or do > the tools already infer that?) Should I put some constraint on the > product terms, to keep the tools from merging the product term and > sum logic? > > I'll experiment with this myself, but perhaps someone here has already > done this, in which case suggestions would be quite welcome. > > Thanks, > Eric If your terms are wide, the carry chains are often a more compact way of doing product terms *and* sums. While short carry chains often tend to take as long as about 3 logic levels, you should be able to perform the entire 25 input, 512 product term, 32 output in 512+32 carry chains or fewer (think of the nand/nand array for implementing sum of products). The number of inputs for each product term would determine the number of elements in the carry chain. I don't believe many tools do a good job of pushing logic into carry chains. If you chose to parameterize a module to implement the product terms, you could have a threshold of 7 product terms to implement as combinatorial logic versus a manual carry chain implementation to keep a balance of delays and resources. The drawback to this technique is that many common product term "chunks" which could be shared between different terms would be in separate carry chains.Article: 97770
Hi, I have been facing the following errors when I tried to generate a bitstream for the Microblaze softcore to be ported on to Virtex 4 FPGA board. Running NGCBUILD ... ERROR:MDT - microblaze_0_wrapper (microblaze_0) - xyz.mhs:46 - failed to copy to implementation ERROR:MDT - mb_opb_wrapper (mb_opb) - xyz.mhs:66 -failed to copy to implementation ERROR:MDT - debug_module_wrapper (debug_module) - xyz.mhs:74 - failed to copy to implementation ERROR:MDT - ilmb_wrapper (ilmb) - xyz.mhs:92 - failed to copy to implementation ERROR:MDT - dlmb_wrapper (dlmb) - xyz.mhs:100 -failed to copy to implementation ERROR:MDT - dlmb_cntlr_wrapper (dlmb_cntlr) - xyz.mhs:108 - failed to copy to implementation ERROR:MDT - ilmb_cntlr_wrapper (ilmb_cntlr) - xyz.mhs:117 - failed to copy to implementation ERROR:MDT - lmb_bram_wrapper (lmb_bram) - xyz.mhs:126 - failed to copy to implementation ERROR:MDT - rs232_wrapper (rs232) - xyz.mhs:133 -failed to copy to implementation ERROR:MDT - rs232_usb_wrapper (rs232_usb) - xyz.mhs:149 - failed to copy to implementation ERROR:MDT - leds_4bit_wrapper (leds_4bit) - xyz.mhs:165 - failed to copy to implementation ERROR:MDT - push_buttons_3bit_wrapper (push_buttons_3bit) - xyz.mhs:179 - failed to copy to implementation ERROR:MDT - dip_switches_8bit_wrapper (dip_switches_8bit) - xyz.mhs:193 - failed to copy to implementation ERROR:MDT - flash_ready_wrapper (flash_ready) - xyz.mhs:207 - failed to copy to implementation ERROR:MDT - sysace_compactflash_wrapper (sysace_compactflash) - xyz.mhs:221 - failed to copy to implementation ERROR:MDT - platgen failed with errors! make: *** [implementation/microblaze_0_wrapper.ngc] Error 2 Done. Earlier when I was using the older version, I never got these errors and everything was working perfectly. But when the licenses got expired, and when I installed the 7.1i versions of EDK and ISE these errors started occuring. Can anyone please throw some light on this issue. I have been stuck with this for the past 4 weeks and am not able to find any resources on the internet for this. It would be great if anyone can let me know about this. Thanks a lot. A.Article: 97771
"Jim Granville" <no.spam@designtools.co.nz> wrote in message news:44016131$1@clear.net.nz... <snip> > Why ? - noise immunity, ease of interface : have you ever tried to > find a power MOSFET that can be driven from 3.3V ? > > -jg Have you ever tried to find a 5V MOSFET that wants to be driven by a 24mA logic drive? It seems that FET drivers (standalone parts with 2A or more drive) are better done outside the FPGA.Article: 97772
John Adair wrote: > If you are connecting to a PC serial port you need a RS232 transceiver chip > between the signals and the FPGA as the voltage levels are not directly > compatible with FPGAs or most other logic chips for that matter. Many > development boards have driver chips on board or like us have a add-on > module for this if you are using one of these. If you have a development > board then the boards with the "fixed" solution will predetermine FPGA pins. > Our approach you assign the pins of the header that your are actually using. Yes. And once you have that wired up, you should configure the FPGA without the uart, but just sending the signal from the receive data pin (from the transceiver) out the send data pin (through the transceiver to the computer). In your terminal program, this should mean anything you type is returned to you either once (vs not at all when the cable is disconnected) or twice (vs only once with the cable disconnected). The difference depends on if your terminal program is running in full or half duplex mode, or if it's hyperterminal if you have the echo local characters box checked in the window that results from the ascii setup button of the properties dialog. Once you've verified the electrical part that way, you can try working on using the uart core itself.Article: 97773
thanks for the reply. i actually just figured out that the board is using a max3232 to talk with rs232. my problem now is with miniuart. precision says its "Current design is not a gate level design." does that mean its not synthesizable? and it also appears that i only have a txd and txd. like 2 pins... is that enough? pzArticle: 97774
You can get away with just TX and RX. The only problem is you get data overflow in your UART and data gets lost. What tool are you using synthesis? The message does sould like you might have behavioural VHDL that most synthesisers won't handle. John Adair Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development Board. http://www.enterpoint.co.uk <zhangweidai@gmail.com> wrote in message news:1141062448.029170.266440@i40g2000cwc.googlegroups.com... > thanks for the reply. i actually just figured out that the board is > using a max3232 to talk with rs232. my problem now is with miniuart. > precision says its "Current design is not a gate level design." does > that mean its not synthesizable? > and it also appears that i only have a txd and txd. like 2 pins... is > that enough? > > pz >
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