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
Kees van Reeuwijk wrote: > I understand that the scarcity of such software is partly because > vendors do not release enough information. Exactly. > Are there any modern devices for which this information *is* > available? Not really, but there is a workaround (MPGA): http://ce.et.tudelft.nl/~reinoud/mpga/README.html This is a hack of course. BTW, I'm working on a much improved architecture, keep an eye on the mailing list for updates (or have a chat in meatspace, note the URL, we must be close;). > IOW, if I wanted to implement an open-source synthesis tool, which > devices should I target? Again, recommendations would be greatly > appreciated. I warmly recommend targetting MPGA :-). Okay, I'm biased. - Reinoud (Spam goes to wanabe, mail to wanadoo!)Article: 37051
Allan Herriman wrote: > > On Thu, 29 Nov 2001 17:02:31 +1300, Jim Granville > <jim.granville@designtools.co.nz> wrote: > <snip> > > What's clamping the pin, and why is a redesign not possible ? > > It's connected to the base of an NPN BJT. The emitter is connected to > ground. There's no resistor. > > It's not my design. I'd like to find out how reliable it's going to > be. > > If it turns out that these things will fail after a month, then I > guess a redesign *is* possible :) > > 2nd best option would replace the BJT with a pin compatible N-ch > MOSFET. A component change isn't as bad as a board change. Look at Digital Mosfets (Fairchild), ( low thresholds ) and also at Digital Transistors, also called Resistor-Transistors by some suppliers. Available in SMD (mostly) and also leaded packages. These have choices of Series/Shunt base resistors, so will solve the problem, so cleanly it will never look like a problem :-) -jgArticle: 37052
Sorry, missed the upper part of Jan's post. Damir "Damir Danijel Zagar" <dzagar@srce.hr> wrote in message news:9u4qkj$brh$1@sunce.iskon.hr... > According to Spartan-IIE datasheet, both 200 parts have the same > amount of block ram (56k). > > Damir > > > "Jan Gray" <jsgray@acm.org> wrote in message > news:9u3knp$53a$1@slb4.atl.mindspring.net... > > "Rick Filipkiewicz" <rick@algor.co.uk> wrote in message > > news:3C0535D4.868C1E65@algor.co.uk... > > > o Do they relate to VirtexE's in the same way as SpartanII did to the > > > Virtex ? Esp wrt timing. > > > > http://fpgacpu.org/#011120: > > > > "You might think that > > > > as Virtex-E is to Virtex, so is Spartan-IIE to Spartan-II > > > > But you would be wrong. According to data sheets, whereas an XCV200 has 14 > > BRAMs (56 Kb) and the XCV200E has 28 BRAMs (112 Kb), in the Spartan-II/E > > family, both the XC2S200 and (alas) the XC2S200E have the same 14 BRAMs > (56 > > Kb). > > ... > > But let us count our blessings. The new Spartan-IIE family is > lower-voltage, > > faster (470 ps TILO (2SxxxE-6) vs. 700 ps TILO (2Sxxx-5)), offers a larger > > part (the 32x48 CLB = 6144 logic cell XC2S300E), supports tons of > different > > I/O signalling standards, and (thank you Xilinx) comes in TQ144 and PQ208 > > QFP packages. " > > > > Jan Gray > > Gray Research LLC > > > > > > > >Article: 37053
I am new to MaxPlus. I have some exprience in Simulation with AtiveHdl and modelsim and also Xlinx. I tryed to simulate a design using MaxPlus. I have compiled it and it has no Error. Now how can I write a test bench for MaxPlus ?? It seems that there is no way to do that in maxplus. I can just make some SCF or VEC file for simulating. But as you know it is not enough at all thanks before for your interest mahdaviArticle: 37054
vbica <vbica@qualcomm.com> writes:
> Hi, I downloaded the JTAG programmer software from Xilinx. I want to
> generate SVF files to program an XC18V00 series configuration PROM.
> I tell the programmer I want to generate SVF. Then I select the
> device, and run some operations on it. I do not have a cable or
> device actually connected to the PC; I just want to get the SVF file
> that would program it. It doesn't appear to work. I tried blank
> check and erase commands, and the SVF contains exactly the same
> code, regardless of which operation I try. The code that gets
> generated doesn't contain any of the expected instructions, either.
> Is this because I'm not actually hooked up to a device? Should this
> work?
I've done this using the xc9500xl. I generate the svf file on a SUN
workstation (you should be able to do it on a PC too), transfer it to
a PC running software from jtag technologies. Then I'll have to hack
the file a little bit to satisfy the jtag software. Here is how I do
it, it might give you some clues:
This is from the tcl script to run all the xilinx tools:
...
# generate svf file
if [catch {exec jtagprog -svf -batch ../jtagprog} msg] {
puts $gOut "ERROR: jtagprog failed, message is:\n$msg"
exit -5
}
# copy the file and hack it to satisfy jtag tech software
file copy -force $top.svf $top.xxf
set s [open $top.xxf r]
set d [open $top.svf w]
puts $d {// $Id: build.tcl,v 1.2 2001/01/25 11:44:17 pegu Exp $}
while {[gets $s line] >= 0} {
# this is a little overkill, but will enable future hacks
if [regexp {(SIR 8 TDI \(ff\) SMASK \(ff\)) (TDO \(01\) MASK \(e3\) ;)} $line all p1 p2] {
puts $d "$p1 ;! $p2"
} else {
puts $d $line
}
}
close $s
close $d
The ../jtagprog.cmd file looks like:
part XC95144XL:pld
program -v pld
quit
"pld" is the name of the top level module.
Good luck
Petter
--
________________________________________________________________________
Petter Gustad 8'h2B | (~8'h2B) - Hamlet in Verilog http://gustad.com
Article: 37055Hi all I use MegaWizard in quartus to generate a ram block with 1 asyn read/1 syn write register file. in megawizard, I do in the following ways: 1 use LPM_RAM_DP+ 2 use APEX20k400E 3 single clock 4 register only the write relate signal, not register the read signal 5 no asyn clear for any register but in the post syn simulation, I do not got the correct read result why? I want the read process some what like a combinational logic, same as a register file read.Article: 37056
Ovidiu Lupas wrote: > > Hi all, > > In my current project I have to implement scrambling and CRCs over a > 128-bit data bus at a clock rate of 100 MHz. My combinatorial areas > are huge and I am having problems meeting the speed requirements. > > Could someone give me an hint how to overcome this problem ? > Any hints will be appreciated. > > Thank you for your time. > > Best regards, > Ovidiu Lupas. You can separate out the inputs from the feedback signals and pipeline the input signals. This will help a lot. However, roughly half the signals will be feedback which you can not pipeline. With such a large data bus, you may still have problems meeting timing. I know someone who may be able to help you further. I will send this message to him. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 37057
Neil Franklin wrote:
>
> mrgs1000@yahoo.com (Mark) writes:
>
> > Kees van Reeuwijk <C.vanReeuwijk@twi.tudelft.nl> wrote in message news:<3fl90u
> k0l3mmebi1703urlud5e91rou5af@4ax.com>...
> > >
> > > I understand that the scarcity of such software is partly because
> > > vendors do not release enough information. Are there any modern devices
> >
> > I would venture to say that the primary road block to open-source
> > tools is that they are too dificult to support and keep current for
> > people to do for free.
>
> As opposed to tons of video and ethernet chips that the Linux people
> seem to have no great problem with?
>
> Just simply support those chips that members of the open source group
> use. And the software users then buy those parts.
>
> Hint to vendors: if your part has open source support, it gets more
> recommendations ("take that one, it works"), and you get to sell more
> of them. I principially buy video and ethernet cards after consultion
> the on-line support databases.
I think this is where the analogy between standard hardware support
under a standard OS and FPGA support under a standard tool fails.
Designers don't EVER want to compromize their choice of chip based on
the tools. That would be more like vacationing in Newark because the bus
is cheaper than taking a plane to the Bahamas!
The idea that open source tool support will significantly impact the
sales of FPGA chips is weak at best. The customers who buy lots of chips
from the FPGA vendors get free tools and often have an FAE parked in
their facility. I worked at one place where they still used brand Z
chips in SPITE of the awful toolset they had to use. This was because
the chip was $10 cheaper than the other brand. It ended up costing them
a lot when they had to make revisions, but this was still the best
solution in terms of PROFIT!!! (brand Z is not meant to be any
particular company!)
> > There are lots of flows for design entry and
> > simulation,
>
> Just support those that the present maintainers use. And use those
> that are supported.
>
> > and new devices are released on a weekly basis. I
>
> Huh? As far as I see it Xilinx has so far created about 9 families
> (2000 3000 4000/Sparten 4000XL/SpartanXL 5200 6200 Virtex/SpartenII
> VirtexE/SpartanIIE Virtex2) in 15 years. Altera has 8 families
> (MAX3000 MAX7000 MAX9000 FLEX6K FLEX8K FLEX10K/ACEX APEX Mercury)
> in over 10 years. Lucent has IIRC 4 families of ORCA. Atmel 2
> families (4000 6000). Actel I do not know, as I can not read their
> website (damn Flash and not HTML alternative). And a few other
> irrelevant manufacturers.
>
> So that makes about 2 falimies per year industrywide to support. Or
> simply only support a few of them and only use those.
But a familiy has some 10 different parts in it. Each of those parts has
many packages and several speeds. Just getting the speed info (critical)
is not an easy problem to solve. Without vendor support, you would be
very hard pressed for anyone to trust your data.
It certainly could be done, but the fact that it has not happened yet is
a good indicator that it is harder than you seem to believe.
> > occasionaly start using parts before they are released so I would not
> > be able to wait for open-source tools to have the support. In fact, I
> > have started designs where the vendors own tools didnt suport the part
> > I was using.
>
> Does not look like you are an average user there. :-)
Actually, I think he is a typical user. I think every place I have
worked has used beta versions of the chips at one time or another. With
a 4 to 6 month design time for an FPGA of any size, it pays to get
started as early as possible.
--
Rick "rickman" Collins
rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.
Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
Article: 37058Allan, See below, Austin Allan Herriman wrote: > On Wed, 28 Nov 2001 08:07:16 -0800, Austin Lesea > <austin.lesea@xilinx.com> wrote: > > Hi Austin, > > [snip off topic stuff] > > > >The maximum current into, or out of a pin on a static basis is stated int > >he absolute maximum DC ratings of the data sheet as 10 mA (notes 4 and 5) > >for voltages forced above or below ground. The AC current is listed as > >less than 100 mA. > > I understand these limits are latchup related. The I/O voltage will > always be between the supply rails, so I don't think these apply. No latchup if you are within the Vcc and ground rails, so you are right. > > > >If you are pulling up a load, as you describe, I expect the current to be > >at least 24 mA, and perhaps as much as 60 mA, with no ill effects, forever > >as long as you are within the Vol, Voh limits as well (ie not dissipating > >a lot of power in the pmos pullup device, as it has a small voltage drop). > > Are you saying that metal migration doesn't happen in Spartan2? The > 4000E devices had a limit of 20mA, based on metal migration. Metal migration is not only poorly understood, it is poorly characterized, and modeled incorrectly. I won't go into it here, but we have done significant experiments in EM, and found that the effects that are promised to occur are not happening. Basically, what wew see is that below a certain current density (and this is >> than what the EM folks consider), no degradation happens (tests ongoing for five years continuously). Above a certain threshold (much, much greater than what the EM guidelines allow), we see a degradation that starts, and then flattens out (ie stops increasing in resistance). Something goes on that isn't good if you go well beyond the limits. Is it Vt shift? Is it hot electron injection? Is it 'curing' of the vias and contacts? Is it EM? We were hoping to get a failure so we could cut it open and analyze. Still waiting. EM tests on foundry structures at temperatures ~260 C are of limited value, as no FPGA ever works where all of the EM data is taken! Basically, I contend that once the 'problem' was solved by AlCu many years ago, the science stopped, and the paper pushers took over. What is even worse, is that copper interconnect has no history, and since there was never a good theory for EM, we must retake all EM data with copper interconnect! > > > The output voltage is clamped well below Voh (actually about 900mV to > 1V above ground), so I'll be dissipating a lot of power in the output. > How do I find out the actual device limits for this case? > > I expect that there will be a few limits: > 1. A maximum steady state current, based on metal migration > 2. A maximum power dissipation in the output transistor(s), based on > localised heating on the die. > 3. A maximum current, with the voltage outside the supply rails, > based on latchup. > > The data sheet has values for (1) but not the others. To know whether > the particular design I'm interested in will work reliably, I require > the other parameters. > > I realise that the output driver wasn't meant to be (ab)used in this > way, but a redesign isn't possible. If you select the minimum standard IO current required to saturate your transistor (ie if the B is 100, and the load is 1 ampere, then you need 10 mA, so choose LVTTL 12 mA) then you are all set. I would also power that bank from a voltage lower than 3.3 V!. You can power the bank from 1.5 V, and thereby limit the stresses on the transistor. > > > Thanks, > Allan. > > >Austin > > > >Allan Herriman wrote: > > > >> Hi, > >> > >> I'm looking for the maximum current I can draw from a Spartan2 output > >> (LVTTL mode) without impairing reliability. I'm only interested in > >> sourcing current (i.e. from the P channel strong pullup). > >> > >> I found Xilinx Answer 4453: > >> http://support.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=4453 > >> that says that the figure is 20mA for 4000E/XL devices, based on metal > >> migration. > >> > >> I couldn't find any figures for Spartan2 though. > >> > >> My next question: how does this scale with the selected I/O standard? > >> E.g. if an LVTTL24 output has an absolute maximum current of 'X' mA, > >> will an LVTTL12 output have an absolute maximum current of 'X' mA, or > >> 'X'/2 mA? > >> I guess it depends on which bits of metalization are the 'critial > >> path'. > >> > >> Thanks, > >> Allan. > >Article: 37059
Hi,I have to design a RGB videocontroller. Using a FPGA, the sync timing and videoRAM scan counters are ready. Now I have great trouble with PALETTE management. I need a fast prom 256x16 or 256x32 100 ns for palette LUT to connect at RAM data outputs,(immediately before the latches and DAC's). Standard (e)proms I have found usually are 8 bit data width and several thousand of address location. I can't find a component more appropriated for palette LUT. Someone know where to find the component I need? Should I use a PAL instead of a non existing prom? THANK you.Article: 37060
Ovidiu Lupas wrote: > > Hi all, > > In my current project I have to implement scrambling and CRCs over a > 128-bit data bus at a clock rate of 100 MHz. My combinatorial areas > are huge and I am having problems meeting the speed requirements. > > Could someone give me an hint how to overcome this problem ? > Any hints will be appreciated. > > Thank you for your time. > > Best regards, > Ovidiu Lupas. Just out of curiosity, is this a paying job or for the open cores thing? I might be able to get you some professional help if you are working on the open cores thing. That was meant in the EE sense, not in the psyc sense of professional help... BTW, you might also look at the implemented logic to see if optimizations are being done on the logic. There are a lot of duplicate terms in the equations you end up with and you should see sharing of logic between the bits. This can also slow you down a bit if done poorly. Not a bad place for hand optimization of the source code. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 37061
Nurit, The "jitter filter" is a register that tells the control logic how often to update the delay line taps. Think of it as how long to "filter" the input phase before deciding to advance or retard the tap in the delay line. I should have said "update rate or the tap adjustment rate." If there is a sudden change of 500 ps in phase, with the default settings it would take ~ 10,000 clocks to adjust back to 0 error with the default settings. With the minimum settings, it would take less than ~100 clocks. Austin Nurit.Eliram@mailandnews.com wrote: > Hi Austin. > I do'nt understand. > What is "jitter filer" ? > What is the "tap rate" ? > > I understand that tap step is ~50 ps. > Do you mean that the minimum time it takes to reach to > the maximum period jitter is 256 cycles ??? > > Bye, > Nurit > > In article <3C050C22.4C93DBEF@xilinx.com>, Austin Lesea says... > > > >answered separately, > > > >jitter filer * 256 = update of the tap rate. > > > >Austin > > > >Nurit.Eliram@mailandnews.com wrote: > > > >> Hi Austin. > >> ThankX for the answer. > >> Since the DLL period jitter is ~150 ps, > >> and the DLL cycle-to-cycle jitter is ~50 ps, > >> > >> I have the following question : > >> > >> Is the worst case is that for 3 consequtive clock cycles the > >> jitter will rise to it's max value of ~150 ps, > >> Or the worst case is that it will rise slower (i.e 100 clock cycles) ? > >> > >> Do I have a measure of time what is the minimum numver of clock > >> cycles for the period jitter to happen ??? > >> > >> Thanks > >> Nurit. > >> > >> In article <3BF94DBD.863C2064@xilinx.com>, Austin Lesea says... > >> > > >> >Nurit, > >> > > >> >From any cycle, to the next cycle, the period out of the Virtex II DCM > >> >(using the DLL feature) can not change by more than a tap value, plus > >> >whatever input jitter may also be present. > >> > > >> >For Virtex II that is ~ 55ps. > >> > > >> >The period jitter is measured by accumulating a histogram of > 200,000 > >> >periods, and fitting a gaussian curve (left and right tail fitting) to get > >> >the peak to peak value. > >> > > >> >Spectral analysis of the histogram shows that the jitter is random, and has > >> >no deterministic component. > >> > > >> >Thus the input jitter going into the DLL may be added to the internal jitter > >> >quadratically to get the output jitter. > >> > > >> >Clock forwarded interfaces have larger margin as a result, as the cycle to > >> >cycle jitter is important as to the sampling of input data by the IOB's. > >> >Worst case, the input data sampling instant error is not the peak to peak > >> >value, but the cycle to cycle value. > >> > > >> >This behavior is completely different than than of a PLL, where the PLL > >> >usually provides some filtering of high frequency jitter components, and > >> >where there is no fixed relationship from an input clock to an output clock > >> >as there is in the DLL (PLL cycle to cycle jitter is bounded only by the > >> >peak to peak jitter, whereas the DLL cycle to cycle jitter is bounded the > >> >delay line tap change). > >> > > >> >Austin > >> > > >> >nurit eliram wrote: > >> > > >> >> Hi. > >> >> I have seen that the period jitter of DLL of virtex-II device is 150 ps. > >> >> > >> >> Can I have any figures about it's cycle-to-cycle jitter ? > >> >> > >> >> ThanKX > >> > > >Article: 37062
Russell, There are some "quick start" helper circuits we have designed and tested that let the power supply come up, and all of the caps charge, and then connect the fpga power. http://www.support.xilinx.com/xapp/xapp451.pdf Austin Russell Shaw wrote: > If the SMPS was connected to the load only after its output > caps had charged, then the current spike should be very short, > and no load would happen on the regulator. > > Austin Lesea wrote: > > > > Brad, > > > > http://www.support.xilinx.com/partinfo/ds003-3.pdf > > > > for virtex. > > > > The power on current is all required at ~ twice the Vt of the core transistors. Somewhere from > > 0.8 to 1.0 Vdc. > > > > A switcher running from 5 V (like the Elantec parts: >95% efficient) would supply a lot of current > > at that moment, being power limited, rather than current limited. Good point. > > > > For pricing on any parts, I can not speak, as I do not know. Our sales partners have their set > > pricing, based on all of the objectives .... so on and so forth. > > > > I know what our suggested pricing is, but that is not going to help you at all. > > > > The fact is that the Virtex II and Virtex E is less expensive to make than Virtex, for the same > > number of LUTs due to the shrink in technology (.22u to .18u to 0.15u). The same is true for > > Spartan II to Spartan IIE. > > > > Moving to 300 mm wafers also increases the yield, so parts on the new 300 mm wafers cost us less > > to make as well. > > > > All of this gets passed along to the customer, through the pricing models. > > > > Austin > > > > Brad Eckert wrote: > > > > > Austin Lesea <austin.lesea@xilinx.com> wrote in message news:<3C0517E1.D2BA1B8C@xilinx.com>... > > > > > > > > In the data sheet there is a 'Supply Current Requirements During Power On' > > > > section for all Xilinx FPGAs. > > > > > > > > http://www.support.xilinx.com/partinfo/ds001_3.pdf > > > > > > > According to the data sheet, this heavy current demand occurs during > > > voltage rampup. Switching regulators put out more current at low > > > voltage, so if 500mA current peak occurs at, say, 0.8V and the > > > regulator's input is 5V then the 5V power supply would see something > > > like 500*0.8/5 mA. About 100 mA with a 80% efficient switcher. > > > > > > As long as you're characterizing startup current, it would be useful > > > to know at what voltage the heaviest current draw occurs. For example, > > > some of my applications use USB, so I have limits on what I can draw > > > from the 5V supply if the device is bus-powered. > > > > > > I thought Virtex was a lot more expensive than Spartan. What price > > > point do you expect for the 2V80 in 2Q 2002? > > > > > > BTW, do you have a link to Virtex power requirements?Article: 37063
I have not used Xilinx DLL before but I am willing to use it. I need to use several clk speed in my design. If I am using XIlinx DLL to generate multiple clock, Will they produce the same duty cycle ? (50% ??) Thanks ! BuzzArticle: 37064
The palette function in video controllers is almost always done in RAM not ROM. This allows you to change what the translations are. For your requirements, the block RAM in Xilinx FPGAs is an excellent match, for both RAM size, and also your speed requirements. Even if for some reason you still want to do this as a ROM (i.e. you wont be changing the translations), these memories can be used in ROM mode as well (just dont connect the write ports, and initialize their value at compile time. If you still want to use external EPROMs (in spite of my excellent advice), just use multiple devices to get the width you need, and tie the high order address lines to a constant, and only use the low 8 address lines for your address in th range 0 .. 255 . Trying to use a PAL for this application is unlikely to succeed. Philip Freidin On 29 Nov 2001 07:46:42 -0800, mariani.raffaele@tiscalinet.it (mariani) wrote: >Hi,I have to design a RGB videocontroller. >Using a FPGA, the sync timing and videoRAM scan counters are ready. >Now I have great trouble with PALETTE management. >I need a fast prom 256x16 or 256x32 100 ns for palette LUT to connect at >RAM data outputs,(immediately before the latches and DAC's). >Standard (e)proms I have found usually are 8 bit data width and several >thousand of address location. I can't find a component more >appropriated for palette LUT. >Someone know where to find the component I need? >Should I use a PAL instead of a non existing prom? > >THANK you. Philip Freidin FliptronicsArticle: 37065
Hi, The best fit would be a Spartan II / Virtex with Block Ram. They can be configured either as 256x16 or 512x8, and they can be initialised. With a single block ram, you can do R[5] G[6] B[5] or you can use two blocks for R[8] G[8] B[8] or even R[10] G[12] B[10] ... With 3 blocks, you can do a double palette system (either swappable on VSync or continuously usable 512 colors (9 bits)) Block Rams are inherently double port. If you take care, you should be able to update the palettes at any time without causing any flicker. Next problem is the D/A converters. You can do it with resistor ladders. If you need to decrease the number of pins / external resistors used for the function, and since your video rate seems low (you asked for a 100ns prom) you can use cascaded DLL to make a 4x clock signal and then use it to encode 2 bits per pin. a small capacitor is added to smooth out the 4x clock signal (first order low pass filter). The whole RGB controller should fit in XC2S15 or XC2S30 and an external frame store (either SRAM or SDRAM). Since you seem to be planing on using VideoRAM, you should make sure that they won't be soon obsolete. BTW, using a SDRAM should allow you to do a full color (24 bits/pixel) controller at virtually no additional cost (4Mx16 chips are dirt cheap these days) and the resulting controller would be simpler too. Documentation : http://xilinx.com/partinfo/ds001_2.pdf hope this helps, Eric. --------------------------------------- mariani a écrit : > Hi,I have to design a RGB videocontroller. > Using a FPGA, the sync timing and videoRAM scan counters are ready. > Now I have great trouble with PALETTE management. > I need a fast prom 256x16 or 256x32 100 ns for palette LUT to connect at > RAM data outputs,(immediately before the latches and DAC's). > Standard (e)proms I have found usually are 8 bit data width and several > thousand of address location. I can't find a component more > appropriated for palette LUT. > Someone know where to find the component I need? > Should I use a PAL instead of a non existing prom? > > THANK you.Article: 37066
Hi folks, does anyone has any experience in SPARTAN II and 5V peripheral components? Are there any known issues about dying FPGAs which are connected to 5V Busses etc. while powering up the system? I've got the strong feeling that SPARTAN 2 could dy, if the 5V components are powered up before the FPGA supply is stable. Is it necessary to keep the peripherals 'disconnected' while powering up? I'm glad about ANY information and espacially experience on the 5V issue and eventually existing power-up sequence constraints. Thanx in advance WolframArticle: 37067
I just found app note 450 about the Spartan II startup current. There is one section discussing the power up of multiple FPGAs that seems to say that you can get by with less than the specified minimum Iccpo. "Assume the supply can source just enough current to meet the total minimum POS current requirement (four times the applicable I CCPO limit). Each FPGA can be modeled as a very low impedance element during power-on. According to this simplified perspective, the power-supply sees four low impedance elements in parallel. If one FPGA takes on a lower impedance value than the others, it will draw more POS current for a shorter time. The other FPGAs accept less current for a longer time. After this fashion, all four FPGAs receive the energy they require to power-on successfully." This seems to be a case where some of the FPGAs do not receive the Iccpo current and yet still power up correctly. I understand that they take longer to bring up, but can't this be done in other cases as well? I would expect Iccpo to be a minimum regardless. No? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 37068
It's appalling that Xilinx would sell a product to design an FPGA/CPLD without the ability to simulate the design unless you buy a $1000+ simulator. Neither the free version nor the eval version allows testing on anything over 500 lines. At that limit on my machine, it simply closes - no slowing down. Does anyone have a lower cost alternative, preferably one that would accept the HDL bencher output? Ed Browne Precision Electronic Solutions "Theron Hicks" <hicksthe@egr.msu.edu> wrote in message news:3BFA68F1.10118196@egr.msu.edu... > > > Leon Heller wrote: > > > Sorry, I've just checked the Xilinx version. It is only for small designs. > > > > -- > > Leon Heller, G1HSM leon_heller@hotmail.con > > http://www.geocities.com/leon_heller > > Low-cost Altera Flex design kit: http://www.leonheller.com > > It will work with much larger designs. It just runs slower. > >Article: 37069
"Jan Gray" <jsgray@acm.org> schrieb im Newsbeitrag news:9u3knp$53a$1@slb4.atl.mindspring.net... > part (the 32x48 CLB = 6144 logic cell XC2S300E), supports tons of different > I/O signalling standards, and (thank you Xilinx) comes in TQ144 and PQ208 > QFP packages. " Who wants a PQ208 package? I dont want to build a brick wall ;-) -- MfG FalkArticle: 37070
Wolfram, Spartan II is 5V tolerant. The IO's are high impedance to a 5V signal until it is configured, and under control of the user logic (then it can be tristate, or drive). http://www.support.xilinx.com/partinfo/ds001_3.pdf page 1 Austin Wolfram Sieber wrote: > Hi folks, > does anyone has any experience in SPARTAN II and 5V peripheral > components? > Are there any known issues about dying FPGAs which are connected to 5V > Busses etc. while powering up the system? > > I've got the strong feeling that SPARTAN 2 could dy, if the 5V > components are powered up before the FPGA supply is stable. > > Is it necessary to keep the peripherals 'disconnected' while powering > up? > > I'm glad about ANY information and espacially experience on the 5V > issue and eventually existing power-up sequence constraints. > > Thanx in advance > > WolframArticle: 37071
Rick, Now we get into the 'voodoo' part of the analysis. With a number of devices in parallel the issue becomes complex. If each device requires a current based on the voltage it sees across its terminals, there is some small variation of this voltage to current behavior from die to die, part to part. There is also some IR drop in each package, and through the board. The text suggests that with four times the current, you will succeed, and discusses how more than four times is not required even though the peak current may exceed the minimum required. It does not imply you can use less than four times the specification. No one can say with any certainty that the four parts will power ON with less than four times the individual ratings, other than: we guard banded the spec (so the actual current is almost surely less), they won't all require the current at the exact same moment, any one device will have the total current available to it if the others are not using it yet (or have finished using it). Austin rickman wrote: > I just found app note 450 about the Spartan II startup current. > > There is one section discussing the power up of multiple FPGAs that > seems to say that you can get by with less than the specified minimum > Iccpo. "Assume the supply can source just enough current to meet the > total minimum POS current requirement (four times the applicable I CCPO > limit). Each FPGA can be modeled as a very low impedance element during > power-on. According to this simplified perspective, the power-supply > sees four low impedance elements in parallel. If one FPGA takes on a > lower impedance value than the others, it will draw more POS current for > a shorter time. The other FPGAs accept less current for a longer time. > After this fashion, all four FPGAs receive the energy they require to > power-on successfully." > > This seems to be a case where some of the FPGAs do not receive the Iccpo > current and yet still power up correctly. I understand that they take > longer to bring up, but can't this be done in other cases as well? I > would expect Iccpo to be a minimum regardless. No? > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 37072
Also, look at Virtex-II, where each dual-ported BlockRAM is four times bigger, and the clock multiplier/divider is much more versatile. Start looking at the XC2V40, the smallest member, which has 512 logic cells (LUT+flip-flop) and four BlockRAMs, and is quite inexpensive. Peter Alfke ======================== Eric wrote: > Hi, > > The best fit would be a Spartan II / Virtex with Block Ram. > They can be configured either as 256x16 or 512x8, and they can be > initialised. > With a single block ram, you can do R[5] G[6] B[5] or you can use > two blocks for R[8] G[8] B[8] or even R[10] G[12] B[10] ... > With 3 blocks, you can do a double palette system (either swappable > on VSync or continuously usable 512 colors (9 bits)) > Block Rams are inherently double port. If you take care, you should be > able to update the palettes at any time without causing any flicker. > > Next problem is the D/A converters. > You can do it with resistor ladders. > If you need to decrease the number of pins / external resistors used for > the function, and since your video rate seems low (you asked for a 100ns > prom) you can use cascaded DLL to make a 4x clock signal and then use > it to encode 2 bits per pin. a small capacitor is added to smooth out the > 4x clock signal (first order low pass filter). > > The whole RGB controller should fit in XC2S15 or XC2S30 and an external > frame store (either SRAM or SDRAM). > > Since you seem to be planing on using VideoRAM, you should make sure > that they won't be soon obsolete. > > BTW, using a SDRAM should allow you to do a full color (24 bits/pixel) > controller at virtually no additional cost (4Mx16 chips are dirt cheap these > days) and the resulting controller would be simpler too. > > Documentation : > http://xilinx.com/partinfo/ds001_2.pdf > > hope this helps, > > Eric. > > --------------------------------------- > > mariani a écrit : > > > Hi,I have to design a RGB videocontroller. > > Using a FPGA, the sync timing and videoRAM scan counters are ready. > > Now I have great trouble with PALETTE management. > > I need a fast prom 256x16 or 256x32 100 ns for palette LUT to connect at > > RAM data outputs,(immediately before the latches and DAC's). > > Standard (e)proms I have found usually are 8 bit data width and several > > thousand of address location. I can't find a component more > > appropriated for palette LUT. > > Someone know where to find the component I need? > > Should I use a PAL instead of a non existing prom? > > > > THANK you.Article: 37073
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