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
This is a multi-part message in MIME format. --------------F59E606C382D8359F21F5837 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andy Peters wrote: > David Hawke wrote: > > > > "Pascal C." wrote: > > > > > A few things: > > > > > > 1. for case 1, we did create a 32-bit registered OE and did PAR with the "-pr b" switch. What tools do you use David? Personnally, I am using Foundation 3.2i.5 (note: I installed SP6 yesterday and MAP crashed pathethically even when started by the GUI!) with FPGA Express 3.4.3. Is it possible that FPGA Express made it impossible for the PAR to recognize the OEs and place them properly (I did prevent it from merging the logic)? > > > > > > > I forgot to mention, the other reason that it may not do this, is if you have the logic sense the wrong way round in the code....(therefore requiring a LUT before the Tri) - Can't remember if it is active high or low to HighZ...Think it is high! > > David, > > According to the Virtex 23 May 2000 datasheet, "The output buffer and > all of the IOB control signals have independent polarity controls." In > fact, a quick peek via FPGA editor shows a four-input mux for the > tristate enable. This means that you should be able to write the output > enable as either active high or active low, and the synthesis tool > should do the right thing. I stand corrected. I was just being lazy! It is probably down to the synthesis tool and its ability to target the architecture. I have had no problems with Leonardo on this... Merry Xmas, Dave > > > > Best thing to do it check the schematic viewer in Synopsys and checking whether there is a LUT in the way....If there is correct the code, and this should work... > > Ah, there's the rub. At least for FPGA Express v3.4 and the XC4KXLA > family, there's a bug: FPGA Express doesn't know about the > polarity-select mux, and if you write your output enable code active > high, an inverter in a CLB is put before the IOB's output enable > control. > > -- a > ---------------------------- > Andy Peters > Sr. Electrical Engineer > National Optical Astronomy Observatory > 950 N Cherry Ave > Tucson, AZ 85719 > apeters (at) n o a o [dot] e d u > > "It is better to be silent and thought a fool, > than to send an e-mail to the entire company > and remove all doubt." --------------F59E606C382D8359F21F5837 Content-Type: text/x-vcard; charset=us-ascii; name="dhawke.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for David Hawke Content-Disposition: attachment; filename="dhawke.vcf" begin:vcard n:Hawke;David Hawke tel;cell:(+44) 778 875 5002 tel;work:(+44) 870 7350 517 x-mozilla-html:TRUE org:<br><img src="http://www.xilinx.com/images/smvirtex.gif" alt="Xilinx"> version:2.1 email;internet:dhawke@xilinx.com title:XILINX Field Applications Engineer adr;quoted-printable:;;Xilinx Northern Europe=0D=0ABenchmark House;203 Brooklands road;Weybridge;; x-mozilla-cpt:;2672 fn:David Hawke end:vcard --------------F59E606C382D8359F21F5837--Article: 28126
Peter Alfke wrote: > > Hal Murray wrote: > <snip> > Come to think of it: > Why limit yourself to just two edegs? You can create a bunch of increasingly > longer clock delays with perhaps 100 ps granularity, and use all of them. Certainly easy to implement in a FPGA, but has some things to watch in the details. A number of cells would be chained, so as to ensure the delay was always > 1 CLK period, and a (frequent) calibrate phase would be needed, as this delay line will be Vcc and Temp dependant. The MSB info is captured by a GATE / Enable process, whilst the LSB (Delay line fraction) would have to be register captured, from the delay line. This could cause some interesting/nasty hand-over aperture problems, as ideally the capture paths should have the same timing models. As in reciprocal counters, you need to do this twice, to find the clock fraction overlap on both leading and trailing PULSE edges. If the PULSE width is long, and precision is important, it could pay to do a clock/Delay calibrate on both edges, so you store 4 numbers for the fractional calc : LeadDelay, Lead100%, TrailDelay, Trail100% Any ideas on the ultimate resolution you could achieve ? -jgArticle: 28127
comp.arch.fpga "lo profile" PLCC sockets Anyone know of a "lo profile" 44 pin PLCC thru-hole socket. A .250 in. (6.3mm) height rather than the typical .320 in. (8.1mm) is needed. The board on this application fits nearly flush against a panel and .320 inches is too high. Hul htytus@iglou.comArticle: 28128
Nial Stewart wrote: > Ray Andraka wrote: > > > > WOrks as long as 1) you can tolerate the ringing that inevitably occurs when the > > driver shuts off, > > Ray, > > I clearly saw this effect on a 'scope when experimenting with > different configurations for driving the op. As you might expect > it gets worse as the DRIVE attribute is increased. > > It's actually very hard to properly terminate the track whilst > pulling the line high as hard as possible. > > Nial. When the buffer turns off, you are inducing a negative current step of -I traveling down the line. Here I is the current still being delivered by the buffer at the instant of turn-off. The net result is a voltage of magnitude -I*Zo superimposed upon the line voltage already established and traveling to the destination. This tells you that until I has decayed to negligible levels, you have accomplished nothing. The timing will be a function of your termination RC time constant and the travel time down the line. The simplest fix here would be to use one or two diodes, or even a zener, to lower the Vcc of the receiver Schmitt trigger so that the worst case Vin,h threshold can be met by the Xilinx Voh output level. This will certainly be the case at Vcc=3.0V so you have lots of room to work with. You terminate the line in a series RC in shunt with the line with R=Z0 and C=Trise/(2.2*R) where Trise is the fastest expected rise time from the Xilinx under this loading. This will yield a reasonable value of C that produces negligible reflection. Having done this, you can use the Schmitt to directly drive any TTL compatible load under light loading. It pulls right up to its rails at 100uA. The outputs are not 5V tolerant but there should be no problem with driving an ACT/HCT type of CMOS input with a leakage pulldown of 33K ohm (100uA limit). In summary then, use the NC7SZ14 single Schmitt trigger from the UHS (CMOS) line running off 3.0V, for a maximum Vin,h threshold of 2.2V, to receive the clock line. This can drive the NC7ST04 (TTL Input and input leakage ~0.1uA) single inverter running off 5V. Use precautionary resistive pulldown at output of Schmitt not to exceed 100uA at Voh=3V.Article: 28129
I have an input that has two flops for destinations. I want one of them to be in the IOB, and the other flop to use a CLB flop, and the tools do that....but it's the wrong one that ends up in the IOB. I have an <all> syn_useioff in the .sdc file, and I also use the map option -pr b...that's how the FFs get in the IOBs in the first place...and I've tried both specifying that specific register as syn_useioff in the .sdc file, as well as the <all>, and I've tried giving the Verilog the /* synthesis syn_useioff = 1 */ on that particular reg statement....nothing has worked yet. When I use look at the technology mapping from Synplicity, it doesn't show what flops are IOB flops...when I bring up the .ncd file (pre PAR) in Floorplanner...the FF for one of the two destination registers is already in the IOB...but it's the wrong one... So, how do I tell Synplicity (preferably) specifically which flop I want in the IOB?Article: 28130
Hi There I tried to synthesize my VHDL file, I used Xilinx Foundation li.3 I have got *.enf, *.alr file I just tried to read schematic from those files but it failed the error is C4061.G not found, Why have I had such error? Thank you very muchArticle: 28131
Hi When I tried to implement my VHDL file by Xilinx Foundation li.3 THe report says Reading NGO file "F:/xilinx/projects/pwma/xproj/ver1/pwma.ngo" ... FATAL_ERROR:Utilities:UtilPtrfilimp.c:140:1.5 - Pointer b29980 already registered. Process will terminate. To resolve this error, please consult the Answers Database and other online resources at http://support.xilinx.com Can anyone give me any suggestion on it? Thanks a lot! QianArticle: 28132
Austin Franklin wrote: > So, how do I tell Synplicity (preferably) specifically which flop I want in > the IOB? Put an area constraint (or a fixed constraint) on the other FF, the one that you don't want in the IOB. -- Phil HaysArticle: 28133
> I'm sorry for issuing a kind of advertisement to this groupe, but let us > intruduce our new product. Why are you apologizing for an announcement that was appropriate to this group? I like things like that. I won't like them if there are 999 similar tools but we aren't at that stage yet. Note that it was a reasonable announcement, not a pile of marketing crap. If you have to apologize in advance, maybe you shouldn't post it. [Spam is one of my hot buttons these days. I just got hit by another headhunter.] -- These are my opinions, not necessarily my employers. I hate spam.Article: 28134
> I just had a look at the online docs, and it's pretty much all covered > in the first few pages of: > > Synthesis and Simulation Design Guide > Chapter 4: Designing FPGAs with HDL > Using Dedicated Global Set/Reset Resource Thanks. Interesting that it doesn't say anything like that in the data sheet. -- These are my opinions, not necessarily my employers. I hate spam.Article: 28135
Bonjour Alex, alexboyer@my-deja.com wrote: > I used the algorithm in the xapp058 from Xilinx to load a serial > eeprom XC18V02 with a xsvf file and it is not working. Where did you take the original SVF (not the compressed XSVF) file? If it was produced by a relatively recent version of JTAGprogrammer, the SVF should be OK. If you don't have the latest one, the WebPack version can be downloaded from the Xilinx website. You just need to compress the SVF into XSVF (source code is given in XAPP058) and execute it at a proper speed. Where (on what SVF line) and what is the error? In some cases, people do not take into account the TCK frequency they use. In the SVF file, there are some "RUNTEST nnn TCK" statements; when the nnn value is low, it can be assumed they mean *real* idle cycles spent in RTI. However, there's also a convention that each cycle is a microsecond (1MHz TCK), thus if you see a large value (such as RUNTEST 100000 TCK), this means to spend 100ms idle in RTI. So, if you use a different TCK frequency, you may actually spend less/more time idling than what is required, and thus proper behavior of the device cannot be garanteed. For example, I believe an XC18V512 needs about 100ms (from the SVF file) to complete a "erase" operation. Using a higher TCK freq means the device will not be given enough time to erase, so that might explain why errors are produced. Étienne.Article: 28136
Anyone know of a nice solution for driving a color VGA display with a FPGA based video controller ?? We want to add VGA output to a product and we happend to have lots of space left in an FPGA on the board. The digital logic is not a problem, the issue is finding a suitable low-cost RAMDAC. Since RAMDACs are no longer used in the mainstream PC industry many are on EOL status and are more expensive than a standalone VGA controller chip. -- StuartArticle: 28137
In article <G5z2tM.BKt@world.std.com>,
sja@world.std.com (Stuart J Adams) writes:
|> Anyone know of a nice solution for
|> driving a color VGA display with a
|> FPGA based video controller ??
|>
|> We want to add VGA output to a product
|> and we happend to have lots of space
|> left in an FPGA on the board.
|>
|> The digital logic is not a problem,
|> the issue is finding a suitable low-cost
|> RAMDAC. Since RAMDACs are no longer used in the
|> mainstream PC industry many are on EOL
|> status and are more expensive than a
|> standalone VGA controller chip.
If you are not planning to add a true colour display, you can use simple R/2R
networks as DACs (maybe restricted to 4 or 6 bit resolution). If you have
plenty of gates left, the RAM should also pose no problem inside the FPGA ;-)
--
Georg Acher, acher@in.tum.de
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
Article: 28138Stuart J Adams wrote: > Anyone know of a nice solution for > driving a color VGA display with a > FPGA based video controller ?? > > We want to add VGA output to a product > and we happend to have lots of space > left in an FPGA on the board. We have a simple circuit that drives a VGA display from an FPGA. The documentation on the circuit is at http://www.xess.com/appnotes/vga.pdf, and the design files are at http://www.xess.com/projects/vga.zip. -- || Dr. Dave Van den Bout XESS Corp. (919) 387-0076 || || devb@xess.com 2608 Sweetgum Dr. (800) 549-9377 || || http://www.xess.com Apex, NC 27502 USA FAX:(919) 387-1302 ||Article: 28139
In article <ee6f135.10@WebX.sUN8CHnE>, "Pascal C." <> wrote: > The pins on which I am trying to reduce the drive are LVTTL. I've > constrained them to a Clock to out of 6 ns, to allow some setup time > (the clock is 131M, so clock period is about 7.8ns). Under 12 mA, it > tells me it can't possibly meet a clock to out of 6 ns. And fails. Your load is 30pF less than the standard load, this gives you the following adjustments relativ to 12mA, 35pF: (Table 15 of the Databook) fast: 12mA => -30x0.44 = -1.32 ns 8mA => -30x0.079 + 1 = -1.37 ns 6mA => -30x0.13 + 3.1 = -0.8 ns 4mA => -30x0.2 + 5.3 = -0.7 ns 2mA => -30x0.41 +13.1 = +0.8 ns This means, 8mA is actually faster than 12mA in your case. You can not use 2mA drivers, and all the other variants differ by only 500ps. If you relax your timing constraints by 700ps you can use any driver you want (except 2mA). If you relax by 1.3ns you can use 8mA drivers and still meet your setup time. CU, Kolja Sent via Deja.com http://www.deja.com/Article: 28140
Austin,
You could use the xc_props attribute from Synplify to tag the flops with the
appropriate Xilinx attribute IOB = (TRUE|FALSE).
The following example should do what you are asking for (note that I had to
use the syn_preserve attribute so that all the flops don't get merged):
module flop_crtl (clk, src, dest1, dest2);
input clk;
input src;
output dest1;
output [7:0] dest2;
reg dest1 /* synthesis syn_preserve = 1
xc_props = "IOB=TRUE" */;
reg [7:0] dest2 /* synthesis syn_preserve = 1
xc_props = "IOB=FALSE" */;
always @(posedge clk)
dest1 <= src ;
always @(posedge clk)
dest2 <= {8{src}} ;
endmodule // flop_crtl
Frédéric
Austin Franklin wrote:
> I have an input that has two flops for destinations. I want one of them to
> be in the IOB, and the other flop to use a CLB flop, and the tools do
> that....but it's the wrong one that ends up in the IOB.
>
> I have an <all> syn_useioff in the .sdc file, and I also use the map option
> -pr b...that's how the FFs get in the IOBs in the first place...and I've
> tried both specifying that specific register as syn_useioff in the .sdc
> file, as well as the <all>, and I've tried giving the Verilog the /*
> synthesis syn_useioff = 1 */ on that particular reg statement....nothing
> has worked yet.
>
> When I use look at the technology mapping from Synplicity, it doesn't show
> what flops are IOB flops...when I bring up the .ncd file (pre PAR) in
> Floorplanner...the FF for one of the two destination registers is already
> in the IOB...but it's the wrong one...
>
> So, how do I tell Synplicity (preferably) specifically which flop I want in
> the IOB?
Article: 28141Jim Granville <jim.granville@designtools.co.nz> writes: > Peter Alfke wrote: > > > > Hal Murray wrote: > > > <snip> > > Come to think of it: > > Why limit yourself to just two edegs? You can create a bunch of increasingly > > longer clock delays with perhaps 100 ps granularity, and use all of them. > > Certainly easy to implement in a FPGA, but has some things to watch in > the > details. > A number of cells would be chained, so as to ensure the delay was > always > 1 CLK > period, and a (frequent) calibrate phase would be needed, as this delay > line will > be Vcc and Temp dependant. About calibration. Couldn't you design a self calibratingsystem? I'm not sure what you are after here, so my mind might wander aimlessly. Having a chain with 100 ps granularity and making it so long that the fastest die under the fastest condition can't fill it in one CLK period. Then just keep track on how many delay elements get filled in one CLK period. Say that you have 1 ns granularity. There's a 10 to 1 diff fastest/slowest, then you need 100 delay steps for fastest (and 10 for slowest). If you inject a signal, you can then measure with an clock how many delay elements were filled. Say you get 53. When you do the measurement of the fraction of signal, you get 32. Divide, and you have your fraction. Or maybe I didn't understand the question? Homann, not speaking for my employer or Xilinx. -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.seArticle: 28142
Can't let this one nit pass without comment... The fact that the input buffer has lots of gain *is* important. The fact that the input buffer has hysteresis (little or lots) is *completely inconsequential* in the context of discussing metastability. Don't think for a second that hysteresis provides any relief from determining your design's susceptibility to metastable "events". -- Bob Elkind, eteam@aracnet.com Peter Alfke wrote: > > Jonas Thor wrote: > > >> Why is the "standard" estimation of MTBF a function of only td, f1 and >> f2? (td = acceptable extra delay, f1 = clock and f2 = data frequency). >> The rise time of the clocks and data signals must matter... or? At >> least for external interfaces. >> >> > > > I don't think so. > 1. There is sufficient gain in the input buffer and even some hysteresis to > make any input rise time look fast once it reaches the internal flip-flop. > > 2. What matters is how often the master latch is caught in the process of > changing and being "in the middle", exactly at the moment when the clock pulse > stops it from being transparent. Then the issue is, how long it takes to fall > to one side. The input rise time should be irrelevant. IMHO > > Peter AlfkeArticle: 28143
IBM used to make some nice RAMDACs. I just checked out www.chips.ibm.com and it seems that they are not making them anymore. Another vendor is Analog Devices. Good luck, -ArrigoArticle: 28144
bob elkind wrote: > > Can't let this one nit pass without comment... > > The fact that the input buffer has lots of gain *is* important. > > The fact that the input buffer has hysteresis (little or lots) > is *completely inconsequential* in the context of discussing > metastability. Don't think for a second that hysteresis provides > any relief from determining your design's susceptibility to > metastable "events". > Peter Alfke wrote: > > I don't think so. > > 1. There is sufficient gain in the input buffer and even some hysteresis to > > make any input rise time look fast once it reaches the internal flip-flop. Hysteresis cannot eliminate metastability, but it can avoid it worsening with slow clock edges - ie it makes the test bench values more portable, and avoids transistion oscillations, which can throw the whole data sheet out the window. - jgArticle: 28145
In the interest of POE (Peace On Earth, for those who never saw Doctor Strangelove) ... everybody's right. Actual implementations of hysteresis consequentially increases input gain because of the positive feedback... (The noise immunity also certainly helps the measurement.) - RLCArticle: 28146
"Austin Franklin" <austin@darkroo98m.com> writes: > I have an input that has two flops for destinations. I want one of them to > be in the IOB, and the other flop to use a CLB flop, and the tools do > that....but it's the wrong one that ends up in the IOB. * Watch out for setup and hold timing. * You could use UCF to specify IOB TRUE, and turn it off in Synplify. Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.seArticle: 28147
Hi I bought an xsv100 board from Xess, which has a Xilinx xcv100 chip on it. With the board came a utility which can send compiled bitstreams to the chip. I'd like to manually generate the bitstreams though, rather than compile them from a vhdl spec though, as my intention is to program it using evolutionary algorithms and I think this would be easier and faster than actually generating vhdl and compiling that then sending that to the chip. Does anyone know where I can find a spec which would show exactly how the bitstreams are interpreted by xcv100 ? I've already had an unsuccessfull look at the Xilinx site (but i've had problems finding what i want there before...) I'm a complete beginner at this, all advice greatfully accepted. Thanks David Sent via Deja.com http://www.deja.com/Article: 28148
In article <3a429674$1_3@news.iglou.com>, htytus@shell1.iglou.com (Hul Tytus) wrote: > comp.arch.fpga > "lo profile" PLCC sockets > > Anyone know of a "lo profile" 44 pin PLCC thru-hole socket. A .250 in. > (6.3mm) height rather than the typical .320 in. (8.1mm) is needed. The > board on this application fits nearly flush against a panel and .320 > inches is too high. > > Hul htytus@iglou.com I have never seen such a socket. Does it have to be a socket? Or can you use a PLCC to PGA adapter from Aries Electronics. http://www.arieselec.com/ They have an adapter that is .082 high, so with a .180 high PLCC, the total would be .262 inches. Alan Nishioka alann@accom.com Sent via Deja.com http://www.deja.com/Article: 28149
Hello, The previous post wants to drive a VGA monitor.(Just generate HS=30KHZ and VS=60 etc..) This is not related to making a VGA compatible graphics board. This requires cloning the BASIC/STANDARD/DEFAULT VGA registers so any WinTel or DOS motherboard will boot and use it successfully. I need to use a Xilinx FPGA to make a VGA compatible graphics card. If not available then how much work is this ? Sincerely Daniel DeConinck High Res Technologies, Inc.
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