Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

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

Custom Search

Messages from 37050

Article: 37050
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: Reinoud <dus@wanabe.nl>
Date: Thu, 29 Nov 2001 09:47:29 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: maximum output current on Spartan2
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Thu, 29 Nov 2001 22:57:04 +1300
Links: << >>  << T >>  << A >>
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 :-)

-jg

Article: 37052
Subject: Re: SpartanIIE
From: "Damir Danijel Zagar" <dzagar@srce.hr>
Date: Thu, 29 Nov 2001 10:57:32 +0100
Links: << >>  << T >>  << A >>
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
Subject: Test Bench for MaxPlus ?
From: mahdavi110@yahoo.com (mahdavi)
Date: 29 Nov 2001 05:14:27 -0800
Links: << >>  << T >>  << A >>
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 

mahdavi

Article: 37054
Subject: Re: Xilinx JTAG programmer: how to generate SVF
From: Petter Gustad <newsmailcomp1@gustad.com>
Date: 29 Nov 2001 14:19:48 +0100
Links: << >>  << T >>  << A >>
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: 37055
Subject: the timing of LPM_RAM_DP
From: shengyu_shen@hotmail.com (ssy)
Date: 29 Nov 2001 05:41:28 -0800
Links: << >>  << T >>  << A >>
Hi 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
Subject: Re: 128-bit scrambling and CRC computations
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 29 Nov 2001 09:31:12 -0500
Links: << >>  << T >>  << A >>
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 FAX

Article: 37057
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 29 Nov 2001 10:21:10 -0500
Links: << >>  << T >>  << A >>
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: 37058
Subject: Re: maximum output current on Spartan2
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 29 Nov 2001 07:46:04 -0800
Links: << >>  << T >>  << A >>
Allan,

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
Subject: palette LUT design(searching ROM)
From: mariani.raffaele@tiscalinet.it (mariani)
Date: 29 Nov 2001 07:46:42 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: 128-bit scrambling and CRC computations
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 29 Nov 2001 10:49:12 -0500
Links: << >>  << T >>  << A >>
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 FAX

Article: 37061
Subject: Re: DLL cycle-to-cycle jitter
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 29 Nov 2001 08:00:52 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: FPGA startup current
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 29 Nov 2001 08:03:36 -0800
Links: << >>  << T >>  << A >>
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
Subject: Duty Cycle & Xilinx DLL
From: #BASUKI ENDAH PRIYANTO# <PH892987@ntu.edu.sg>
Date: Fri, 30 Nov 2001 00:28:48 +0800
Links: << >>  << T >>  << A >>
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 !

Buzz


Article: 37064
Subject: Re: palette LUT design(searching ROM)
From: Philip Freidin <philip@fliptronics.com>
Date: Thu, 29 Nov 2001 16:28:51 GMT
Links: << >>  << T >>  << A >>
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
Fliptronics

Article: 37065
Subject: Re: palette LUT design(finding Virtex / Spartan II)
From: Eric <erv_fedupwith_spam@sympatico.ca>
Date: Thu, 29 Nov 2001 11:47:00 -0500
Links: << >>  << T >>  << A >>
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
Subject: Spartan2 problems with 5V periphery
From: w.sieber@gmx.de (Wolfram Sieber)
Date: Thu, 29 Nov 2001 16:54:57 GMT
Links: << >>  << T >>  << A >>
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 

Wolfram

Article: 37067
Subject: Re: FPGA startup current
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 29 Nov 2001 12:13:49 -0500
Links: << >>  << T >>  << A >>
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 FAX

Article: 37068
Subject: Re: Modelsim
From: "Ed Browne, Precision Electronic Solutions" <ed_b_pes@swbell.net>
Date: Thu, 29 Nov 2001 17:17:48 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: SpartanIIE
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Thu, 29 Nov 2001 18:34:29 +0100
Links: << >>  << T >>  << A >>


"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
Falk




Article: 37070
Subject: Re: Spartan2 problems with 5V periphery
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 29 Nov 2001 09:49:01 -0800
Links: << >>  << T >>  << A >>
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
>
> Wolfram


Article: 37071
Subject: Re: FPGA startup current
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 29 Nov 2001 09:58:02 -0800
Links: << >>  << T >>  << A >>
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 FAX


Article: 37072
Subject: Re: palette LUT design(finding Virtex / Spartan II)
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Thu, 29 Nov 2001 10:04:16 -0800
Links: << >>  << T >>  << A >>
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
(removed)


Article: 37074
(removed)




Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

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

Custom Search