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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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 106425

Article: 106425
Subject: Re: JOP as SOPC component
From: Tommy Thorn <foobar@nowhere.void>
Date: Sat, 12 Aug 2006 23:51:30 -0700
Links: << >>  << T >>  << A >>
Martin Schoeberl wrote:
... snip
>>> Or does the Avalon switch fabric, when registered, take this
>>> information into account for the waitrequest of the master?
>> It does.
> 
> That's a reason to go with fix wait states!
> 
> Or a bus specification that counts down the number of
> wait states ;-)

The problem with both is that it would impose undesirable constraints on 
slaves. Imagine the case of a good SDRAM controller which tracks open 
pages. Read latency depends on what it's currently doing (idle, 
refreshing, busy with another request, etc) and whether the access hit 
on open page. In this case it _could_ perhaps give an early 
"read-data-in-2-cycles" strobe, but dealing with that would be a nasty 
complication for the interconnect structure that has to be able to 
handle any combination of multi-masters and random assortment of slaves.

It is feasible for internal protocols, tailor-made for the parts it 
connects, but IMO not for a generalist interconnect like Avalon.

FWIW, I used to do exactly what you suggest (latch and mux), but it 
didn't scale for me as the interconnection grew and was expensive in 
both resources and cycle time (not to mention the added complication and 
opportunity for bugs). Adopting the Avalon style template (which is 
obvious IMnsHO) freed so many resources (mine and the FPGAs), enabling 
performance improvements elsewhere. Having spent way too much time and 
energy on exactly this point, I'd be very interested in others insights.

> BTW: Did you take a look into the SimpCon idea?

I just did, after writing the above :-), but my point still stands. 
AFAICT, SimpCon doesn't support multiple outstanding requests from any 
one master and therefore doesn't distinguish between being able to 
accept a new request and and being done with a request.

I'm sure SimpCon works for you, but for me it would be not much better 
than Wishbone.

> Dreaming a little bit: Would be cool to write an
> open-source system generator (like SOPC builder) for
> it. Including your suggestion of an open and documented
> specification file format.

Sure, though I suspect writing all this would be trivial compared to 
coming to an agreement on how the interface should work :-)

>>> Again, one more cycle latency ;-)
>> Again, nope not if done correctly.
> 
> I think we finally agreed, did we?

I'm not KJ, but I think the issue is clear.  Following the template 
would incur an extra cycle for you (assuming JOP couldn't be fixed in a 
different way). It definitely possible to do what you suggest and avoid 
that cycle at the expense of extra overhead and logic (the glitch 
doesn't matter for internal deployment).

Tommy

Article: 106426
Subject: Re: virtex II inner organisation
From: jbnote@gmail.com
Date: 13 Aug 2006 00:54:20 -0700
Links: << >>  << T >>  << A >>
Hello Flo,

> Hi everyone,
> I'm trying to deal with readback and scrubbing into a XC2V1500 FPGA.
>
> I've got a problem identifying the Major Adress and the Minor Adress
> when I'm doing a readback.
>
> Does anyone know how to determine it?

This information is available in the virtex-II Useg Guide (ug002.pdf)
available on Xilinx's website. Page 314 and following for the current
revision (configuration details). Table 4-17 coupled with FAR decoding
is what you're looking for.

Based on this info I've already written working code for reading and
dumping xc2v2000 *bitstreams* (crc computation, luts, brams...).

I can release it under the GPL if you can help me to get it to work
with readbacks (how far is that from pure bitstreams ?) and the 1500
(small amount of work here).

JB


Article: 106427
Subject: Re: ISE Webpack 8.1 adder wierdness
From: Sylvain Munaut <tnt-at-246tNt-dot-com@youknowwhattodo.com>
Date: Sun, 13 Aug 2006 10:35:45 +0200
Links: << >>  << T >>  << A >>
Antti wrote:
> Todd Fleming schrieb:
> 
>> Ralf Hildebrandt wrote:
>>> I strongly guess that the flipflop has normal and inverted output.
>>> Therefore you get the inversion for free (for the cost of these flipflops).
>>> And furthermore it seems to be, that the pure combinational solutions
>>> are slightly to complex to fit into 8 LUTs (the inversion is too much to
>>> fit).
>>>
>>> Ralf
>> I don't see any reference to an inverted output on the flipflops in the
>> Spartan 3 data sheet.  From looking at the slice diagram in the DS and
>> the schematic for ADSU8 in the library guide, it looks like the LUTs
>> should be able to absorb the inverter on b.
>>
>> Todd
> 
> any signal inversion at LUT inputs are of couse "absorbed" so it
> should no make any difference if signals are inverted or not.

Well not always. In this case, yes it should because only 'b' is
inverted. But if 'a' and 'b' were to be inverted, that couldn't be
pushed into the LUTs because one of the two input has to feed the
carry chain. The only modification that could be done on 'a' is AND
it (with the MULAND (not sure of the name)).

The slice stucture allow pretty tricky/complex stuff to be done in just
1 layer, but I found it's often quite difficult to make xst understand ...


     Sylvain

Article: 106428
Subject: Re: Gaisler on a Spartan 3E Starter Kit?
From: Frank Buss <fb@frank-buss.de>
Date: Sun, 13 Aug 2006 10:56:41 +0200
Links: << >>  << T >>  << A >>
David M. Palmer wrote:

> Alternatively, has anybody put together a complete opencores project
> for this board with the Wishbone bus, a processor, RAM, Ethernet, and
> other things that they could share?   There are lots of nice little
> pieces in OpenCores, but I don't see good documentation and examples
> for putting it all together.

I'm working on this. RS232 sender/receiver and DS2432 one-wire ROM id
reader is finished:

http://www.frank-buss.de/vhdl/spartan3e.html

The next big thing will be ethernet and DDR SDRAM support.

I'm very new to FPGA and VHDL programming, so any comments would be
appreciated, especially if the Wishbone interface is implemented correctly,
because I plan to use this interface for my other components, too.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 106429
Subject: Re: Clock domain crossing (again)
From: burn.sir@gmail.com
Date: 13 Aug 2006 01:58:47 -0700
Links: << >>  << T >>  << A >>
jai.dhar@gmail.com wrote:
...
> Actually, I forgot to clarify one aspect. The FPGA is itself generating
> the 2.048M clock (divided from a 8M192) as well as a framing pulse.
> That's easy enough to do of course... does this add any complications
> if the FPGA is generating the pulses? I would think it makes it
> easier...




I am no expert, but my guess is that if you are generating one clock
from the other, things are much easier. And the 1/25 ratio gives you
more than enough time to adjust the setup/hold times if you have
problems with those.

On the other hand, if you had two independent clocks, the clock error &
jitter might have forced you to use an asynchronous FIFO.

-Burns


Article: 106430
Subject: Re: Maximum Current Draw of FPGA
From: nico@puntnl.niks (Nico Coesel)
Date: Sun, 13 Aug 2006 11:05:39 GMT
Links: << >>  << T >>  << A >>
"Nevo" <nevo_n@hotmail.com> wrote:

>I've reviewed the docs briefly but didn't find this information.

They specify a maximum current of 24mA sink/source per pin. For 96
pins, this would add up to 2.3 A.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 106431
Subject: Re: Maximum Current Draw of FPGA
From: "PeteS" <PeterSmith1954@googlemail.com>
Date: 13 Aug 2006 04:38:55 -0700
Links: << >>  << T >>  << A >>
Nico Coesel wrote:
> "Nevo" <nevo_n@hotmail.com> wrote:
>
> >I've reviewed the docs briefly but didn't find this information.
>
> They specify a maximum current of 24mA sink/source per pin. For 96
> pins, this would add up to 2.3 A.
>
> --
> Reply to nico@nctdevpuntnl (punt=.)
> Bedrijven en winkels vindt U op www.adresboekje.nl

For the OP question, assuming 3.3V I/O power and a typical forward
voltage on the LED of 2V, then the total current into the device is
about 320mA (3.33mA per pin) which should be fine.

Note that LED forward voltage varies quite a lot - at low currents it
may be as low as 1.5V (for some devices). That would add about 50% to
the total, to ~450mA total. Without knowing the exact device it's hard
to be really specific.

I second the comment about incomplete specs - in this particular case,
I don't think the OP has anything to worry about though.

Cheers

PeteS


Article: 106432
Subject: Re: Embedded clocks
From: "PeteS" <PeterSmith1954@googlemail.com>
Date: 13 Aug 2006 04:53:32 -0700
Links: << >>  << T >>  << A >>
rickman wrote:
> Jim Granville wrote:
> > anything better than RC, has starting time issues, so usually runs
> > all the time, and that has power penalties.
>
> RC is not even an oscillator without other componets so it really is
> not a solution.  I can get an oscillator that runs on 1 mA of current,
> costs under $0.50 and has plenty of accuracy to do any of the above
> protocols.  So async serial is ok.  One in and one out.
>
> > > I don't see one wire as being any simpler than a UART.  One wire is
> > > just bit async rather than byte async.  You still need a timer to time
> > > the bits.
> >
> > build them both, and count the macrocells :)
> >
> > UARTs need (commonly) /16 resettable counter on RX, and a /16 non
> > resetable counter on TX, plus the byte buffers in both directions.
> >
> > So that's at least 8 macrocells running higher than the bit-rate,
> > plus appx 4 more do do the framing, vs 3-4 for PWM bus.
>
> A PWM bit level signal still has to do all the higher level stuff of
> counting the bits in a word etc.  So if there is an savings, it would
> be very little.
>
> > PWM Osc is gated-monostable type at 4x bit rate - so power is lower.
> > A 3 bit Gray counter handles RxSample, TxWindow, and Sync detect
> >
> > Simulating all this is not that easy, on today's tools, which are
> > designed for a master-clock approach.
> >
> >
> > CPLDs have no problems with speed, but the host speed may be a stumbling
> > block. Philips talked about 3.4MHz i2c, but nothing seems to have hit
> > the streets. I see they now have a FM+ spec, which is high drive i2c,
> > at 1MBd, also well within CPLD's reach.
>
> The host would be another CPLD.  The "host" has to take in two SPI
> running near 100 kHz and four discrete signals.  I have no info on how
> the SPI data is framed.  I2C is done in bytes, but my understanding is
> that SPI has no defined protocol, it really is a non-standard standard.
>  I will have to get more info on how the SPI busses are being used
> before I can decide if this will even work.
>
>
> > > SPI would work too, but would use all four pins leaving us no spares.
> >
> > SPI can work with 3 wires, if that helps.
>
> I could put an address on the SPI bus like I2C does it.  I can't recall
> at the moment why I felt it would need a fourth pin.  I think because
> of flagging which of the two SPI ports was running at that moment.  But
> that can be encoded in the data stream so I guess it could leave a pin
> free.
>
>
> > > A UART interface could use two wires, one for transmit and one for receive.
> >
> > > The word
> > > size can be application specific with dedicated bits for discrete
> > > signals.  Most importantly, I think it will be the smallest in a CPLD.
> >
> > How many IO's do you need, on how many addresses ?
>
> I don't understand.  Do you mean the discrete signals?
>
> > Do they need dataDirection register control, and read-back, or
> > are simpler fixed OUT and IN acceptable ?
>
> No, just four outputs.  They are triggers with timing information, but
> I don't know how precise they need to be.
>
> > 64 Macrocells sounds plenty, could even manage this in 32 Macrocell parts.
>
> You did not account for the two SPI ports that are being multiplexed.
> Without more info on the protocol on the SPI ports, I can't count FFs.
> But each one will need a buffer since the link will have to run much
> faster than either of the two SPI ports.  Also I don't even know if
> this will work since SPI is full duplex, IIRC.  As you shift out data
> read data is coming back, right?  Or is it still half duplex with the
> read data and write data never happening at the same time?  I would not
> be able to buffer words and do full duplex.  That sounds incompatible
> to me.

SPI is a spec in search of itself.
There are some variants to it. For a decent overview of the different
types, you could look at the interface specs on this device I use
http://products.zarlink.com/product_profiles/ZL38001.htm

(Look at the microport section).

One of the issues I ran into on the original Motorola implementation
was that the last data bit (lsb) was only valid for half a bit time -
so I had to generate a quadrature clock. (That was in the early 90s).

As you are doing it for yourself, you have no such limitation. SPI can
run at up to 4Mb/s on commercial parts, and I see no reason a CPLD
could not handle that.

Cheers

PeteS


Article: 106433
Subject: Re: Embedded clocks
From: "rickman" <spamgoeshere4@yahoo.com>
Date: 13 Aug 2006 05:15:58 -0700
Links: << >>  << T >>  << A >>
Jim Granville wrote:
> rickman wrote:
>
> > Jim Granville wrote:
> >
> >>anything better than RC, has starting time issues, so usually runs
> >>all the time, and that has power penalties.
> >
> >
> > RC is not even an oscillator without other componets so it really is
> > not a solution.  I can get an oscillator that runs on 1 mA of current,
> > costs under $0.50 and has plenty of accuracy to do any of the above
> > protocols.  So async serial is ok.  One in and one out.
>
> RC osc would use the CPLD - not sure what 'other components' you mean.
>
> If you are happy with 1mA and 50c, then that's fine.
>
> I see in my notes, Core ICC figures of ~20uA @ 15KHz for a CPLD RC osc,
> at a cost of a few cents. ( and appx 50uA at 1MHz )

How do you get a CPLD to reliably oscillate with an RC?


> Again, it depends on your yardstick.  When you are working with 32
> Macrocell CPLDs, as I do often, a saving of 8 macrocells can be
> very important.

I agree, but I am not sure there is any savings.  Both methods have to
do the same work in framing bits and words so I don't see where the
savings would come in.  That would require a more detailed analysis or
design.  I suppose the one wire protocol might be able to have more
commonality between the rx and tx, but a half duplex uart could likely
do the same thing.

There are other considerations.  If I can clearly show that a one-wire
approach would work and fit the part while a uart design would not,
that would be clear evidence.  But I am currently working (the emphasis
on *currently*) in a very political environment where being right is no
guarantee of being "right".  If a more "trusted" designer decided that
he was uncomfortable with the one-wire approach it would be gone
regardless of the facts.


> <snip>
> >>64 Macrocells sounds plenty, could even manage this in 32 Macrocell parts.
> >
> >
> > You did not account for the two SPI ports that are being multiplexed.
> > Without more info on the protocol on the SPI ports, I can't count FFs.
>
> I thought this was a multi-slave plus master problem - you seem to be
> talking only about the master above - what are the slaves ?

I think I explained what I was building, but it may be scattered over
several different posts.  The "thing" I am trying to figure out is in
essense a multiplexer and demultiplexer of several signals.  There are
two interfaces that need to be brought out through a cable.  The
connector is virtually out of pins and we don't want to make it larger.
 Each interface has an SPI port with a CE since it drives multiple
slaves running at lowish rates.  The interface also has two discrete
signals which are mostly for timing of control.  The SPI port is used
to send setup commands and the discrete signals say "do it now".  We
have added four pins to the connector before remembering that the
interface for each was a total of 6 pins and that we actually needed
two ports.  Is it unlikely that we can add a total of 12 pins to the
connnector.  So we need a mux.

The SPI ports can not be multiplexed together in the simple way since
they have separate masters that are not synchronized.  So to multiplex
this will require capturing the data from both ports and muxing it at a
higher speed along with the discrete signals.  I am limited by not
knowing the format of the data on the SPI busses.

It just occured to me that I really don't need to know the format of
the data if I just treat the signals as arbitrary data streams.  I can
sample them at high enough rates that the timing information is not
significantly distorted and send them across in a very, very simple
scheme.  I can sample each one in a round-robin manner at say 1 MHz for
a total clock rate of 10 MHz (10 signals in one direction, 2 in the
other).  This interface would need a clock, datain, dataout and frame
sync.  That will fill the four pins, but would also be flexible enough
that other discrete signals could be added with a small increase in
frequency.

One BIG advantage to doing it this way is that the latency is no more
than 2 clock cycles or 0.2 uS.  I am also very confident that it could
be done in a 32 cell CPLD.  The slave would be clocked by the
interface, so it does not need a crystal or other timing device.  The
master can be a bit more complex since it is inside the unit, but
likely a ~10 MHz clock can be provided.  The only remaining issue is
finding a CPLD that is low power and can be made tolerant of the
external signals.  I would hate to have to buffer all 16 signals in the
cable.


>   SPI works like the simplest 8 bit shift registers, so it is duplex
> capable.
>
>   Most SPI memories, work in half-duplex - they read the address info,
> while floating SerialOUT, and then ignore SerialIN, while
> driving serial out (if doing a read).
>
>   If you have to slave to two separate SPI streams, that you have little
> control over, that could get complex very quickly.

Yes, that is the part that has me concerned.  But by explaining it to
you, I think I have figured out the best way to approach this.  We'll
see if I can get the multiplexer to fit in terms of power and any other
constraints that pop up later.

Thanks for listening and offering your advice.


Article: 106434
Subject: Re: Maximum Current Draw of FPGA
From: "Slurp" <slip@slap.slop>
Date: Sun, 13 Aug 2006 13:18:41 +0100
Links: << >>  << T >>  << A >>

"Nevo" <nevo_n@hotmail.com> wrote in message 
news:uOvDg.5670$zc2.3643@trnddc06...
> I've reviewed the docs briefly but didn't find this information.
>
> I'm playing with a XC3S400 in a 256 BGA on the Digilent board. If I were 
> to use all the available I/O pins to drive LEDs (that's 104 of them), and 
> do something silly like turn 'em all on at once, will I exceed the maximum 
> current draw of the chip and let out the magic smoke?
>
> The eight red LED's on the board are driven directly from the I/O pins 
> through 390 ohm resistors.
>
> I am planning on attaching a green LED to each of the 96 I/O pins exposed 
> on the connectors through 390 ohm resistors.
>
> Thx,
>
> -Nevo
>

That's a really naff way of driving LED's.

Instead drive them from the FPGA IO configured as open collector (ie 
tristate with the tristate buffer input connected to ground, and the 
tristate control as your  input. Then connect the LED to the IO, supplying 
the other end of the LED via a resistor to your supply.

That way you considerably reduce the FPGA power dissipation to that of the 
saturated output drivers - the bulk of the power being dissipated in the 
external resistors.

Slurp 



Article: 106435
Subject: Re: Embedded clocks
From: "Brian Davis" <brimdavis@aol.com>
Date: 13 Aug 2006 05:34:57 -0700
Links: << >>  << T >>  << A >>
rickman wrote:
>
> I had not given the question much thought when I posed it and I see now
> that all the "self clocking" schemes are framed in some rate and the
> clock is recovered given a reference.
>
 If you can use one of the small CPLD/FPGA parts with a DLL/PLL
(e.g. MachXO) at the far end, you should be able to press the {D|P}LL
into service for clock recovery using a specially constructed waveform.

 There was thread last year about sending bidirectional data over a
SATA cable without needing a CDR at the far end where I suggested
a clock phase modulation scheme:

  http://groups.google.com/group/comp.arch.fpga/msg/42d1840c981c64e6

  - send a clock with fixed rising edges and +/-90 degree
     phase modulation of the falling edges

  - divide by two to strip the phase modulation -> clean ref. clk

  - double then phase shift for a mid-period sample clock

 If the {D|P}LL phase detector & ctl logic only uses leading edges,
and doesn't mind the wild duty cycle swings, you could skip the
divide-by-2 and double steps.

 I haven't tried that out yet, but I don't see any fundamental problems
with it ( other than wasting BW vs. other modulation schemes. )

Brian


Article: 106436
Subject: Problem of uninstall modelsim
From: "fl" <rxjwg98@gmail.com>
Date: 13 Aug 2006 06:03:24 -0700
Links: << >>  << T >>  << A >>
Hi,
I have installed Xilinx webpack and modelsim in my computer. I find it
is rather perhaps because of the memory not large enough. The webpack
still searches for modelsim for simulation even I uninstalled it
(modelsim). I even tried uninstalled webpack and reinstalled it. It
still looks for modelsim (of course, I have set the option back in the
dialog box of simulator).
Could you tell me how to correct this ?


Thank you very much.


Article: 106437
Subject: Re: Problem of uninstall modelsim
From: "fl" <rxjwg98@gmail.com>
Date: 13 Aug 2006 06:04:37 -0700
Links: << >>  << T >>  << A >>

fl wrote:
> Hi,
> I have installed Xilinx webpack and modelsim in my computer. I find it
> is rather perhaps because of the memory not large enough. The webpack
> still searches for modelsim for simulation even I uninstalled it
> (modelsim). I even tried uninstalled webpack and reinstalled it. It
> still looks for modelsim (of course, I have set the option back in the
> dialog box of simulator).
> Could you tell me how to correct this ?
>
>
> Thank you very much.

Sorry, the version of webpack is 8.2 and modelsim is 6.2 XE.


Article: 106438
Subject: Re: Maximum Current Draw of FPGA
From: nico@puntnl.niks (Nico Coesel)
Date: Sun, 13 Aug 2006 13:08:00 GMT
Links: << >>  << T >>  << A >>
"Slurp" <slip@slap.slop> wrote:

>
>"Nevo" <nevo_n@hotmail.com> wrote in message 
>news:uOvDg.5670$zc2.3643@trnddc06...
>> I've reviewed the docs briefly but didn't find this information.
>>
>> I'm playing with a XC3S400 in a 256 BGA on the Digilent board. If I were 
>> to use all the available I/O pins to drive LEDs (that's 104 of them), and 
>> do something silly like turn 'em all on at once, will I exceed the maximum 
>> current draw of the chip and let out the magic smoke?
>>
>> The eight red LED's on the board are driven directly from the I/O pins 
>> through 390 ohm resistors.
>>
>> I am planning on attaching a green LED to each of the 96 I/O pins exposed 
>> on the connectors through 390 ohm resistors.
>>
>> Thx,
>>
>> -Nevo
>>
>
>That's a really naff way of driving LED's.
>
>Instead drive them from the FPGA IO configured as open collector (ie 
>tristate with the tristate buffer input connected to ground, and the 
>tristate control as your  input. Then connect the LED to the IO, supplying 
>the other end of the LED via a resistor to your supply.
>
>That way you considerably reduce the FPGA power dissipation to that of the 
>saturated output drivers - the bulk of the power being dissipated in the 
>external resistors.

Xilinx FPGAs (like almost all digital CMOS devices) have complementary
push/pull output stages. It doesn't matter whether you sink or source
current, the output stage will be saturated in either case unless the
programmed output current is exceeded.

If an FPGA is used, I think it is easy to connect the LEDs in a matrix
and deploy a nifty multiplexing scheme.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 106439
Subject: Re: Embedded clocks
From: "rickman" <spamgoeshere4@yahoo.com>
Date: 13 Aug 2006 06:15:33 -0700
Links: << >>  << T >>  << A >>
Brian Davis wrote:
> rickman wrote:
> >
> > I had not given the question much thought when I posed it and I see now
> > that all the "self clocking" schemes are framed in some rate and the
> > clock is recovered given a reference.
> >
>  If you can use one of the small CPLD/FPGA parts with a DLL/PLL
> (e.g. MachXO) at the far end, you should be able to press the {D|P}LL
> into service for clock recovery using a specially constructed waveform.
>
>  There was thread last year about sending bidirectional data over a
> SATA cable without needing a CDR at the far end where I suggested
> a clock phase modulation scheme:
>
>   http://groups.google.com/group/comp.arch.fpga/msg/42d1840c981c64e6
>
>   - send a clock with fixed rising edges and +/-90 degree
>      phase modulation of the falling edges
>
>   - divide by two to strip the phase modulation -> clean ref. clk
>
>   - double then phase shift for a mid-period sample clock
>
>  If the {D|P}LL phase detector & ctl logic only uses leading edges,
> and doesn't mind the wild duty cycle swings, you could skip the
> divide-by-2 and double steps.
>
>  I haven't tried that out yet, but I don't see any fundamental problems
> with it ( other than wasting BW vs. other modulation schemes. )

Thanks for the ideas.  I was not aware of the MACHXO parts.  They are
suprizingly dense and cheap.  Web pricing at Atmel for the 256 LUT part
is around $5 in moderate quantities.

I assume I would need a 2x clock to generate the 90 degree skewing of
the trailing edge or even a 4x clock if I don't want to play tricks
with using opposite phases clocking FFs.

This could work and would only use two pins, one in each direction.
But the device itself would be pushing the boundary of what I would
like to use.  The smallest part is 256 LUTs and the smallest package is
a 100 pin Chip Scale BGA at 8x8 mm.  There is one universal truth in
FPGAs and CPLDs; if you have a lot of IO, you will have a lot of logic
and if you have a lot of logic you will have a lot of IO.  They don't
put large deivces in low pin count packages, ever!

The power consumption of the MACHXO is a bit high.  I don't have an
exact number, but the standby current starts at 14 mA.  But this is not
out of the ballpark and I will keep the idea in mind since it can use
half the pins of the other approach I have in mind.


Article: 106440
Subject: Arbiter schemes?
From: "Davy" <zhushenli@gmail.com>
Date: 13 Aug 2006 07:23:24 -0700
Links: << >>  << T >>  << A >>
Hi all,

I am reading OVL example
(http://www.eda.org/ovl/pages/main_examples.html) and confused with 4
arbitration schemes:
Fixed priority; Round Robin: simple, look-ahead-1,look-ahead-16?

Is there any book or reference talk about arbiter schemes?

Thanks!
Davy


Article: 106441
Subject: Re: Maximum Current Draw of FPGA
From: "PeteS" <PeterSmith1954@googlemail.com>
Date: 13 Aug 2006 07:36:19 -0700
Links: << >>  << T >>  << A >>
Nico Coesel wrote:
> "Slurp" <slip@slap.slop> wrote:
>
> >
> >"Nevo" <nevo_n@hotmail.com> wrote in message
> >news:uOvDg.5670$zc2.3643@trnddc06...
> >> I've reviewed the docs briefly but didn't find this information.
> >>
> >> I'm playing with a XC3S400 in a 256 BGA on the Digilent board. If I were
> >> to use all the available I/O pins to drive LEDs (that's 104 of them), and
> >> do something silly like turn 'em all on at once, will I exceed the maximum
> >> current draw of the chip and let out the magic smoke?
> >>
> >> The eight red LED's on the board are driven directly from the I/O pins
> >> through 390 ohm resistors.
> >>
> >> I am planning on attaching a green LED to each of the 96 I/O pins exposed
> >> on the connectors through 390 ohm resistors.
> >>
> >> Thx,
> >>
> >> -Nevo
> >>
> >
> >That's a really naff way of driving LED's.
> >
> >Instead drive them from the FPGA IO configured as open collector (ie
> >tristate with the tristate buffer input connected to ground, and the
> >tristate control as your  input. Then connect the LED to the IO, supplying
> >the other end of the LED via a resistor to your supply.
> >
> >That way you considerably reduce the FPGA power dissipation to that of the
> >saturated output drivers - the bulk of the power being dissipated in the
> >external resistors.
>
> Xilinx FPGAs (like almost all digital CMOS devices) have complementary
> push/pull output stages. It doesn't matter whether you sink or source
> current, the output stage will be saturated in either case unless the
> programmed output current is exceeded.
>
> If an FPGA is used, I think it is easy to connect the LEDs in a matrix
> and deploy a nifty multiplexing scheme.
>
> --
> Reply to nico@nctdevpuntnl (punt=.)
> Bedrijven en winkels vindt U op www.adresboekje.nl

The OP is driving the LEDs with about 2.5 - 3.3 mA. That's not very
bright in the first place, so any multiplexing scheme would need to
change the resistors.

That said, doing it by multiplexing (driving with about 15mA pulses for
example) would minimize multi-pin currents.

Cheers

PeteS


Article: 106442
Subject: Re: Maximum Current Draw of FPGA
From: Rene Tschaggelar <none@none.net>
Date: Sun, 13 Aug 2006 16:46:13 +0200
Links: << >>  << T >>  << A >>
Nevo wrote:

> I've reviewed the docs briefly but didn't find this information.
> 
> I'm playing with a XC3S400 in a 256 BGA on the Digilent board. If I were to 
> use all the available I/O pins to drive LEDs (that's 104 of them), and do 
> something silly like turn 'em all on at once, will I exceed the maximum 
> current draw of the chip and let out the magic smoke?
> 
> The eight red LED's on the board are driven directly from the I/O pins 
> through 390 ohm resistors.
> 
> I am planning on attaching a green LED to each of the 96 I/O pins exposed on 
> the connectors through 390 ohm resistors.

LEDs do not need 20mA, in most cases, 1mA is
clearly visible.

Rene
-- 
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

Article: 106443
Subject: Re: Maximum Current Draw of FPGA
From: nico@puntnl.niks (Nico Coesel)
Date: Sun, 13 Aug 2006 15:46:18 GMT
Links: << >>  << T >>  << A >>
"PeteS" <PeterSmith1954@googlemail.com> wrote:

>Nico Coesel wrote:
>> "Slurp" <slip@slap.slop> wrote:
>>
>> >
>> >"Nevo" <nevo_n@hotmail.com> wrote in message
>> >news:uOvDg.5670$zc2.3643@trnddc06...
>> >> I've reviewed the docs briefly but didn't find this information.
>> >>
>> >> I'm playing with a XC3S400 in a 256 BGA on the Digilent board. If I were
>> >> to use all the available I/O pins to drive LEDs (that's 104 of them), and
>> >> do something silly like turn 'em all on at once, will I exceed the maximum
>> >> current draw of the chip and let out the magic smoke?
>> >>
>> >> The eight red LED's on the board are driven directly from the I/O pins
>> >> through 390 ohm resistors.
>> >>
>> >> I am planning on attaching a green LED to each of the 96 I/O pins exposed
>> >> on the connectors through 390 ohm resistors.
>> >>
>> >> Thx,
>> >>
>> >> -Nevo
>> >>
>> >
>> >That's a really naff way of driving LED's.
>> >
>> >Instead drive them from the FPGA IO configured as open collector (ie
>> >tristate with the tristate buffer input connected to ground, and the
>> >tristate control as your  input. Then connect the LED to the IO, supplying
>> >the other end of the LED via a resistor to your supply.
>> >
>> >That way you considerably reduce the FPGA power dissipation to that of the
>> >saturated output drivers - the bulk of the power being dissipated in the
>> >external resistors.
>>
>> Xilinx FPGAs (like almost all digital CMOS devices) have complementary
>> push/pull output stages. It doesn't matter whether you sink or source
>> current, the output stage will be saturated in either case unless the
>> programmed output current is exceeded.
>>
>> If an FPGA is used, I think it is easy to connect the LEDs in a matrix
>> and deploy a nifty multiplexing scheme.
>>
>> --
>> Reply to nico@nctdevpuntnl (punt=.)
>> Bedrijven en winkels vindt U op www.adresboekje.nl
>
>The OP is driving the LEDs with about 2.5 - 3.3 mA. That's not very
>bright in the first place, so any multiplexing scheme would need to
>change the resistors.
>
>That said, doing it by multiplexing (driving with about 15mA pulses for
>example) would minimize multi-pin currents.

With multiplexing, the OP could do without resistor and use DCI or
current limiting in the FPGA. Saves a whole bunch of resistor. DCI
would be nice because the current can be adjusted by an 1 resistor (or
potmeter).

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 106444
Subject: Re: Maximum Current Draw of FPGA
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 13 Aug 2006 09:12:26 -0700
Links: << >>  << T >>  << A >>
It seems like everybody agrees that this is not a problem.
But there remains the complaint about "missing specs".
Obviously, a dedicated LED driver should specify the current per pin,
and also total. That device has little else to spec.
An FPGA has already thousands of other, more important specifications.

So we do not specify max current per pin.
There are two limitations: power and metal migration.
For a given current, the power depends on the voltage drop, and it
depends on the strength of the output, and that is programmable. This
would make the spec very complicated.
Moreover, power per individual pin is not so important, since silicon
is such a good thermal conductor.
The other constraint is metal migration, which has become better since
we now use Cu instead of Al in the metallization. 40 mA is tolerable
"forever".
The real limitation is the junction temperature, which depends on total
device power consumption in conjunction with the thermal resistance.
And we specify this exhaustively.

In short:
 Don't worry about the current (if it is below 40 mA per pin
continuously).
Instead, worry about the junction temperature.
And Xilinx gives you lots of data to figure that out.

Peter Alfke, Xilinx Applications (from home)
=====================
Rene Tschaggelar wrote:
> Nevo wrote:
>
> > I've reviewed the docs briefly but didn't find this information.
> >
> > I'm playing with a XC3S400 in a 256 BGA on the Digilent board. If I were to
> > use all the available I/O pins to drive LEDs (that's 104 of them), and do
> > something silly like turn 'em all on at once, will I exceed the maximum
> > current draw of the chip and let out the magic smoke?
> >
> > The eight red LED's on the board are driven directly from the I/O pins
> > through 390 ohm resistors.
> >
> > I am planning on attaching a green LED to each of the 96 I/O pins exposed on
> > the connectors through 390 ohm resistors.
>
> LEDs do not need 20mA, in most cases, 1mA is
> clearly visible.
>
> Rene
> --
> Ing.Buero R.Tschaggelar - http://www.ibrtses.com
> & commercial newsgroups - http://www.talkto.net


Article: 106445
Subject: Re: Maximum Current Draw of FPGA
From: Austin Lesea <austin@xilinx.com>
Date: Sun, 13 Aug 2006 09:21:56 -0700
Links: << >>  << T >>  << A >>
Nevo,

Answers in line, below,

Austin

Nevo wrote:
> I've reviewed the docs briefly but didn't find this information.
> 
> I'm playing with a XC3S400 in a 256 BGA on the Digilent board. If I were to 
> use all the available I/O pins to drive LEDs (that's 104 of them), and do 
> something silly like turn 'em all on at once, will I exceed the maximum 
> current draw of the chip and let out the magic smoke?

Two specifications here you must observe:  absolute maximum junction 
temperature, and IO pin absolute maximum voltages.  For what you 
describe, this being a transient, firstly, the IOs remain tristate until 
your design has control over them, so as long as YOU do not turn them 
all on at once, your question is even simpler to answer: nothing 
happens.  No problem.

If you do turn them all on at once, then you would have to leave them ON 
until the junction temperature went nuts (assuming you had no heatsink 
or airflow, and your power supply had the current).  That is the ONLY 
way to damage the device from what you have so far described.

> The eight red LED's on the board are driven directly from the I/O pins 
> through 390 ohm resistors.

OK.  What strenth setting are you placing on the IO driver?  If the 
strength chosen is something like LVCMOS 24 mA, then the IR drop on the 
driver is very small, and there is practically no power developed in the 
device, and you really have nothing to worry about.

But, if you chose the weakest driver, then the driver dissipates power, 
and the device will get hotter.  As long as you stay below the abs max 
temp, no damage.

I would choose the weakest and slowest driver, just for the signal 
integrity issues, but I would watch that the internal power stayed 
within my overall package power dissipation budget.

> I am planning on attaching a green LED to each of the 96 I/O pins exposed on 
> the connectors through 390 ohm resistors.

And this is important, why?  Seems to me how they are wired has nothing 
to do with your question.  My personal preference are those blue leds, 
they are much sexier than red, yellow, or green.


The IOB is incredibly robust:  after all the PCI and GTP+ IO standards 
specify currents of 45 mA to 70 mA being there forever, so we had to 
design it to take that.  The number Peter mentions of 10 mA is when you 
force the pin to go below ground, or above Vcco, as then you are forward 
biasing the IO device diodes, either pumping electrons into the 
substrate, or pushing them into the Vcco rail.  10 mA is there as a 
guideline.  We certainly still need to observe the abs max specs, even 
then, for device temperature, and pin and supply voltages.

Perhaps the specification is too simple, as we allow you to do many 
bizarre things (which may not be very useful, but they will not cause 
any damage, or reduce the device lifetime).

Perhaps you are not usd to FPGA design, where you have to have many 
choices, and are in complete control?  Our specification is written to 
allow you to do whatever it is you desire.

In fact, the more specifications we add to the data sheet, the less 
useful the device is, and the more business we potentially lose.  A case 
where more is not better, and less is ideal.  In fact, even less abs max 
would be even better (we only place a specification there when we know 
it will affect reliability).

After all, we are a FPGA, and you decide what it will do, not us.  As 
long as it works, and is within the abs max specs, it won't hurt the device.

Article: 106446
Subject: Re: Virtex 4 could not work correct,is it damaged?
From: Austin Lesea <austin@xilinx.com>
Date: Sun, 13 Aug 2006 09:30:28 -0700
Links: << >>  << T >>  << A >>
Borry,

Not enough information in your posting.

Is this one device?  Out of how many?  If this is one of only one 
devices, maybe it was destroyed by an ESD zap?  Perhaps it sustained 
damage when the power supplies were applied incorrectly?

Resistance of a power rail is useless.  At what voltage?  How measured?

Better to know is what is not working.  You mentioned the DCMs, how is 
the output not correct?  If a "bad" DCM sometimes works, then how can 
this be the device is bad?  Have you checked you input clocks for jitter 
and if they are within the ranges specified for the DCM?

I would submit a webcase, online, with every single detail, if you wish 
to get an answer.

Austin



Borry.Wang@gmail.com wrote:

> One chip of Virtex 4,SX35F668,is used in my PCB board,When the board is
> first assembled,the FPGA could performance very well,but about a month
> later,the FPGA could not work correctly even download with the same
> bitstream file once worked OK. I check the operate current of the total
> board,the current is about 0.5A lower than normal(5V input
> voltage),After the review every detail parameters of each ICs on the
> board,the static resistor of 2.5V is much higher than
> before(approximate 800ohm now but approximate  10ohm before),the 2.5V
> is only provided to FPGA`s Vccaux and two banks`s Vcco.because the
> Vccaux is provided to DCM,so I write a Program to test the 8 DCMs in
> Virtex 4 SX35,the test result is that:every time I turn on the power
> and load the same bitstream file to FPGA through JTAG,the output of the
> 8 DCMs is not the same!Sometimes,2 or 3 DCMs`s output is not
> correct,and the DCM lock signal keep low,the worst condition is 5 of 8
> DCMs`s output is not correct, and the correct DCM and incorrect DCM is
> not fixed during each time.
> 
> could anyone give me some advice to solve the problem?
> 

Article: 106447
Subject: Altera Cyclone-II FIFOs
From: Michael Laajanen <michael_laajanen@yahoo.com>
Date: Sun, 13 Aug 2006 20:16:48 +0200
Links: << >>  << T >>  << A >>
Hi,

I have some problems with async clocked FIFOs in Altera Cyclone-II.

When simulating the design I receive data out from the FIFO after one 
clock pulse, but the timings diagram from the FIFO code generator 
indicates that I need to wait 3 clock cycles AND have the READ active 
during these 3 clock cycles!

 From what I understand the simulation model coudl be wrong or the 
timings diagram is wrong.

What is correct in this, anyone been using these FIFOs and knows 
something about this?


/michael

Article: 106448
Subject: Xilinx Webpack inferring BRAMS, RedHat version
From: Jeremy Wood <jerwood@charter.net>
Date: Sun, 13 Aug 2006 13:37:48 -0500
Links: << >>  << T >>  << A >>
I have been working on a design that uses BRAMs to implement a register 
file using the Windows version of the Xilinx Webpack. Recently, I have 
moved to a Linux based laptop to continue working on this project and 
have setup the RedHat version without much trouble. However, the same 
code I use for the register file synthesizes as distributed RAM under 
the RedHat version instead of BRAMs. I have been able to force it to use 
BRAMs using the synthesis settings, but I would like to know if there is 
something else I can do to have the tool infer it as a BRAM without 
having to make this change, since I will be adding components to my 
design soon that will have to be mapped to distributed RAM. Any ideas or 
am I stuck?

Thanks,
Jeremy

Article: 106449
Subject: Re: Embedded clocks
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Mon, 14 Aug 2006 07:31:59 +1200
Links: << >>  << T >>  << A >>
rickman wrote:
> Jim Granville wrote:
> 
>>rickman wrote:
>>
>>
>>>Jim Granville wrote:
>>>
>>>
>>>>anything better than RC, has starting time issues, so usually runs
>>>>all the time, and that has power penalties.
>>>
>>>
>>>RC is not even an oscillator without other componets so it really is
>>>not a solution.  I can get an oscillator that runs on 1 mA of current,
>>>costs under $0.50 and has plenty of accuracy to do any of the above
>>>protocols.  So async serial is ok.  One in and one out.
>>
>>RC osc would use the CPLD - not sure what 'other components' you mean.
>>
>>If you are happy with 1mA and 50c, then that's fine.
>>
>>I see in my notes, Core ICC figures of ~20uA @ 15KHz for a CPLD RC osc,
>>at a cost of a few cents. ( and appx 50uA at 1MHz )
> 
> 
> How do you get a CPLD to reliably oscillate with an RC?

Choose one with Schmitt pin options (also important if you want to try 
i2c, where the slow edges will mess with non-schmitt CPLDs ).

That's Atmel's ATF1502BE (32MC), or CoolrunnerII devices.

You can make 1 pin, 2 pin, or 3 pin Oscillators - the more pins,
the better the precision, and less it depends on the thresholds.

The numbers I gave are for ATF1502BE.

-jg




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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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