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 48800

Article: 48800
Subject: Re: Pin locking Virtex 2 FPGA
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Thu, 24 Oct 2002 11:22:59 -0700
Links: << >>  << T >>  << A >>

M Schreiber wrote:


> I guess the question I am asking is what are some good rules
> of thumb (I know that these rules can't always be applied) for
> choosing pin configurations before a design is complete?  Should I let
> the tools choose most of my pins and modify that list or should I
> group buses together with timing constraints, etc? 



Devices in the Virtex2 / Apex20k class are
quite insensitive to pinout of standard IOs.
Let the place and route take the first cut and use that as reference
for the board level schematic -- but go ahead and line up buses
in a sane order if you like. I expect you will see no difference
in place and route and your board layout might be easier.

  -- Mike Treseler



Article: 48801
Subject: Re: Xilinx POS Power On Surge Current
From: "MikeJ" <pacman@fpgaarcade.com>
Date: Thu, 24 Oct 2002 19:35:12 +0100
Links: << >>  << T >>  << A >>
oops, that will teach me to make comments here after a few drinks !
I tried to make two points, and failed to make either.

1) During the power up sequence the supplies must come up monotonically and
stabilise within ~ 50ms. I have not had any problems here, even though I
have a lot of decoupling on each device, as the dc-dc converters providing
vcc_int current limit ok to a high value.

2) During configuration, and just after, I believe you get quite large but
short duration current demands ( 3 - 5 A). However the 'mid range' bulk tant
or big ceramic caps I place under the device on each corner supply this
need. I also configure the devices one at a time to ease the pain on the
supply. comments ?

Cheers,
MikeJ

"Tim" <tim@rockylogic.com.nooospam.com> wrote in message
news:ap7as7$qoo$1$8300dec7@news.demon.co.uk...
> MikeJ wrote
>
> > I have powered 18 v300e devices from a 12 amp dc/dc device without
> > problems - the large bulk caps took the strain during config, as long as
the
> > supply limits in a sensible fashion.
>
> MikeJ - this was probably a typo, but the problem is _before_
> config, during power-up.
>
>
>



Article: 48802
Subject: Re: FPGA XC4005E
From: skintigh@yahoo.com (Seth)
Date: 24 Oct 2002 11:42:12 -0700
Links: << >>  << T >>  << A >>
LOL, I stand corrected.  

I meant 5.0.8/a (not 4.0.8/a, and not to be confused with 5.0.8a or
5.0.8a/a)
Make sure you are not confusing support for XC4000E, X, 4005, etc for
plain vanilla XC4000 support.  Unless something changed very recently,
Synplify stopped supporting the XC4000 with 5.0.8/a.  You could also
call your own tech support and ask.

I also did not know I had the option of Windows 3.1.  ROFL.


Ken McElvain <ken@synplicity.com> wrote in message news:<3DB745D7.9040709@synplicity.com>...
> I don't think you tested very much.  There never was a 4.x version of
> Synplify, we skipped from 3.x to 5.x because of beliefs in Asia about
> the number 4.  The current version of Synplify supports
> XC4000 and XC3000 designs.
> 
> - Ken
> 
> Seth wrote:
> 
> > You can use Synplify 4.0.8/a (from the mid 90's, extremely buggy, only
> > runs on a Sun, last version to support XC4000*) and Xilinx XACT (Y2K
> > incompliant, only runs on an HP, last version to support XC4000*). 
> > This is what they STILL use at Lockheed Martin/BAE Systems when
> > configuring XC4000s.
> > 
> > Or you can throw them in the trash and use Atmel's clone and some real
> > software.
> > 
> > Atmel even promises to support their products, not just have buyers
> > beta-test them and then get left in the cold.  You can even call Atmel
> > tech support, a HUMAN will answer on the first ring**, and have a
> > software patch made for you and emailed to you in days!!!  I swear!  I
> > almost fainted.
> > 
> > * Versions after this may support XC4005E, I only tested for XC4000
> > ** I haven't tested this in the last 6 months, your milage may vary
> > 
> > "Mauro Pintus" <triac11@yahoo.com> wrote in message news:<lw1t9.29916$dj7.189247@tornado.fastwebnet.it>...
> > 
> >>Hi, I need to configure an old FPGA XC4005E, but in the WebPack is not
> >>present (i've tried 4.2 and 3.3 version).
> >>Any one know witch is the program that i have to use and where i can find
> >>it?
> >>
> >>Thanks
> >>      Mauro
> >>

Article: 48803
Subject: Re: Pin locking Virtex 2 FPGA
From: "MikeJ" <pacman@fpgaarcade.com>
Date: Thu, 24 Oct 2002 19:46:00 +0100
Links: << >>  << T >>  << A >>
I would like to add that if you can register all your IO signals, and the
tools successfully place these registers in the IO cell, then the pin
placement is not quite so critical. I am normally concerned more with the
PCB routing, especially on the big BGA's, and try and get the layout as
point to point and 'simple' as possible. For example, grouping busses
together and at least getting them on the correct side of the chip can save
pcb layers and several inches of track (and it might work).

However, routing delays in the chip are usually more significant than the
internal logic delay, so you may need to think about the placement of
critical timing strobes.
Virtex2's are faster than 2e's, and unless you wish to go > 150 Mhz, or have
some combinatorial paths, you will be fine.
b.t.w. I think the tools pick pin locations completely at random, or at
least it seems that way.
/MikeJ

"Theron Hicks" <hicksthe@egr.msu.edu> wrote in message
news:ap9ctg$cos$1@msunews.cl.msu.edu...
> Mike,
>     Just my experience, but for what it is worth...
> I have been working on a design based on the Spartan2E series chip.  The
> FPGA is composed of a high spped timer counter, some serial d/a and a/d
> signals and some other random i/o.  The FPGA is being pushed in terms of
> speed (200 MHz internal clock, 100 MHz external clock) but not in terms of
> being full (less than 50% utilization).  Tying down my I/O signals myself
in
> a somewhat inteligent fashion improved the timing results substantially
> compared to the locations randomly picked by ISE.  By the way,
floorplanning
> did not have nearly the impact on speed that locking i/o pins did.
> Re-adjusting my picked locations to improve the "layout-ability" of the
> circuit board did not substantially damage the timing of the circuit.
> Remember that this circuit required speed but was not highly complex and
did
> not fill the chip beyond about 50%.  I suspect that complex interaction
> between portions of the circuit and/or high circuit utilization (in terms
of
> CLBs used) might likely cause problems with the circuit's maximum clock
> speed.
>
> Theron Hicks
>




Article: 48804
Subject: Re: Xilinx POS Power On Surge Current
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Fri, 25 Oct 2002 07:57:07 +1300
Links: << >>  << T >>  << A >>
MikeJ wrote:
> 
> oops, that will teach me to make comments here after a few drinks !
> I tried to make two points, and failed to make either.
> 
> 1) During the power up sequence the supplies must come up monotonically and
> stabilise within ~ 50ms. I have not had any problems here, even though I
> have a lot of decoupling on each device, as the dc-dc converters providing
> vcc_int current limit ok to a high value.
> 
> 2) During configuration, and just after, I believe you get quite large but
> short duration current demands ( 3 - 5 A). However the 'mid range' bulk tant
> or big ceramic caps I place under the device on each corner supply this
> need. I also configure the devices one at a time to ease the pain on the
> supply. comments ?

 I believe the peak is BEFORE config, and occurs at that Vcc where all
the 
P and N fets do not drive enough to be 'hard digital', but Vcc is high
enough
for conduction to start. Can be uA per fet, but multiply that by all the
FETS....

 What is needed, is a curve trace of Icc / Vcc for a choice of Slew
rates,
and with some current limits on Vcc.

 A spice model of the effect would also be good :)

 A key issue is, with ?? current limit, does it just take 
'longer to get over the hump', or can the Vcc stall permanently.

-jg

Article: 48805
Subject: GlobalReset hogging routing resources
From: "FPGA admirer" <>
Date: Thu, 24 Oct 2002 12:12:55 -0700
Links: << >>  << T >>  << A >>
Hello all, hopefully you can help me with some idea as to what is causing my problem.  Instead of the GSR being distributed on a global buffer, the GSR input is being sent to a CLB then from that CLB being sent to every other CLB in the design that uses Global Reset.  This is causing extremely high fanout for this signal and I believ consuming massively unneeded routing requirements.  I did not notice this problem till I saw the hgih fanout in the floorplanner and checked the design in the FPGA editor, and wow! this signal is all over the chip in nearly every CLB but not on a global net.

During synthesis I receive this warning: 

Warning: No global set/reset (GSR) net could be used in the design becuase the design contains the unlinked cell '/ver7-Optimized/AWGFIFOIntergace/AddressCounterRAM'

The RAM referred to was generated using Logiblox, although I do not understand what the unlinked cell means.  The RAM is being used by the design and doesn't seem to be optimized out from my observation.  

I have specified an input pad on the chip as GlobalReset.  This signal is instantiated onto the GSR input of the STARTUP block.  I then pass the GlobalReset signal onto each of my VHDL modules.  Am I supposed to pass the GSR signal instead of the GlobalReset?  I have two clock buffers in use that are not giving me this error and there are global/clock buffers still available.

Thanks for any help!

Article: 48806
Subject: Equivalent clock logic?
From: ae <>
Date: Thu, 24 Oct 2002 12:16:03 -0700
Links: << >>  << T >>  << A >>
Hello <br>
<br>
The following logic was used in about 40 processes in a design I am working on:<br>

if rising_edge(clock30) then<br>
if (Clock90 = '0')<br>
(do so and so)<br>
end if;<br>
end if;<br>
<br>
Clock90 is a 66% duty cycle 90ns clock while Clock30 is a 50% duty cycle 30ns clock. Clock90 is generated from Clock30. 
To attempt to reduce the amount of routing resources required by the prior logic I created the following process:<br>
<br>
if rising_edge(clock30) then<br>
if (Clock90 = '0')<br>
Clock90_generated <= '1';<br>
else<br>
Clock90_generated <= '0';<br>
end if;<br>
end if;<br>

Clock90_generated thus becomes a 33% duty cycle 90ns clock. I then distributed Clock90_generated on a global buffer and replaced code as shown in the first example with the following:<br>
<br>
if rising_edge(Clock90_generated) then<br>
(do so and so)<br>
end if;<br>
<br>
This change did result in much better satisfaction of my desired timing constraints. When loaded into the device however, the system does not work... it does work with the unchanged code. I know some will say if it isn't broken don't fix it, however I am expanding the design and running into severe routing issues (with no option to upgrade chips).<br>
<br>
I have simulated the generation of my Clock90_generated clock and also viewd it on an oscilloscope from a test point on the chip and it is produced as I wished. Assuming the error is due to the code I introduced I have been able to think of no other reason for it not to function at present than that I may be misusing the 'rising_edge()' function. Is it appropriate to use rising_edge(Clock90_generated)?<br>
<br>
The reason I wonder about this is that in simulation, the logic in the first example will execute on the rising edge of clock90... which seems surprising to me unless the simulator, due to the no rise/fall time sees a rising edge of a signal as having a value of zero (and at the same time one?)<br>
<br>
Any insight on the rising_edge function or other help would be appreciated.<br>
<br>
Thank you<br>
<br>
AE

Article: 48807
Subject: Re: Xilinx POS Power On Surge Current
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 24 Oct 2002 12:22:04 -0700
Links: << >>  << T >>  << A >>


MikeJ wrote:

> <snip>
> 2) During configuration, and just after,

No, it is only during power-on, before the beginning of configuration, that you
get the extra current. Once configuration has started, you as a user affect the
(much smaller) current by the clock rate, first CCLK, later user clock(s).

Peter Alfke



Article: 48808
Subject: Re: Silly Virtex 2 Pro question...
From: Ray Andraka <ray@andraka.com>
Date: Thu, 24 Oct 2002 19:22:41 GMT
Links: << >>  << T >>  << A >>
Generated.

Austin Lesea wrote:

> Ray,
>
> Jitter generated, or jitter tolerated?
>
> If this is jitter tolerated, it might meet the spec (we just haven't tested to it).
>
> Austin
>
> Ray Andraka wrote:
>
> > One of the places I was hoping to use them was for SMPTE-292 HDTV serial
> > transmission, which is 1.485 Gbps.  Unfortunately it looks like the jitter spec
> > for the PLL doesn't meet the SMPTE292 specification, so while it can probably be
> > used, it is not compliant.
> >
> > Austin Lesea wrote:
> >
> > > Nick,
> > >
> > > The MGTs (serdes) in V2 Pro do all of the clock and data recovery on the
> > > incoming differential pair, and provide the proper transmit serial on its
> > > output differential pair.
> > >
> > > Physically at a minimum you need a transformer for isolation for a four wire
> > > interface, and an optical to electrical converter for a fiber interface.
> > >
> > > There are plenty of other details on the DC balnce of the code, what the bits
> > > mean, etc. that have to also be taken into account.
> > >
> > > But yes, they work.  And yes, they are inside the Virtex II Pro.  And yes,
> > > they do both clock and data recovery on RX and also do TX as they have the 20X
> > > multiplier PLLs to do that job.
> > >
> > > They were designed for the serial backplane business, not the 1G Ethernet
> > > business.  There is also the Serial ATA business that is similar (but not
> > > really).  There are many projects by folks to see where we fit without any
> > > issues (square pegs in square holes), and then we have those applications that
> > > folks are interested in working a bit harder to do (square pegs in round
> > > holes).
> > >
> > > As these other applications are made to work reliably, you will see them
> > > announced.
> > >
> > > Since we are using the Connexant serdes IP in Virtex II Pro, we are already
> > > compatible with their ICs, as well as many other serdes designed for backplane
> > > and on pcb high speed serial links.
> > >
> > > Again, that is the focus of the product.
> > >
> > >  http://www.xilinx.com/esp/optical/xlnx_net/oif.htm
> > >  http://www.xilinx.com/esp/optical/xlnx_net/pci_express.htm
> > >  http://www.xilinx.com/esp/optical/xlnx_net/xaui.htm
> > >  http://www.xilinx.com/xlnx/xil_prodcat_landingpage.jsp?title=Aurora
> > >  http://www.xilinx.com/esp/optical/xlnx_net/fibre_chan.htm
> > >  http://www.xilinx.com/esp/optical/xlnx_net/inf_band.htm
> > > etc etc etc
> > >
> > > All built in, no extra ICs required.
> > >
> > > Austin
> > >
> > > "Nicholas C. Weaver" wrote:
> > >
> > > > The Xilinx Answer Record states that the RocketI/Os on the V2Pro have
> > > > been tested and verified to work with 1000BASE-SX (fiber Gb ethernet,
> > > > multimode fiber).
> > > >
> > > > The media for 1000BASE-T however is a 4 pair differential signaling,
> > > > rather than the serial send/receive of the fiber standards.
> > > >
> > > > Are there low cost solutions for driving 1000BASE-T ethernet using the
> > > > RocketI/Os?
> > > >
> > > > --
> > > > Nicholas C. Weaver                                 nweaver@cs.berkeley.edu
> >
> > --
> > --Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930     Fax 401/884-7950
> > email ray@andraka.com
> > http://www.andraka.com
> >
> >  "They that give up essential liberty to obtain a little
> >   temporary safety deserve neither liberty nor safety."
> >                                           -Benjamin Franklin, 1759

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 48809
Subject: Re: Silly Virtex 2 Pro question...
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Thu, 24 Oct 2002 19:35:03 +0000 (UTC)
Links: << >>  << T >>  << A >>
Ray Andraka <ray@andraka.com> wrote:
: Generated.

: Austin Lesea wrote:

:> Ray,
...
:> > Austin Lesea wrote:
:> >
...
:> > > > The Xilinx Answer Record states that the RocketI/Os on the V2Pro have
...

While I honor the discussion, the quoting style makes archives nearly unusable.

About 100 line added for a short confirmation....

Bye

-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 48810
Subject: Re: Silly Virtex 2 Pro question...
From: Dali <dadicool@ifrance.com>
Date: Thu, 24 Oct 2002 12:48:42 -0700
Links: << >>  << T >>  << A >>
Just one small detail: if you go with the BASE-FX fiber GigE, no media 
conversion has to be done. The data has to be supplied to the internal 
RocketI/O in 8 bits format and the SERDES Core qill do the 8b/10b 
conversion and the differential output is perfect for the Optical 
tranceiver. No media converters needed.

Hope this helps.

Dali

Nicholas C. Weaver wrote:

> THanks.  Background: This is what I want to build AFTER I file my
> dissertation, (unless someone else has built it for me), so still
> several months off:
>
> A V2Pro-7 module, with ~2 Gb ethernet (ideally BASE-T copper, but I
> can live with BASE-?X fiber and get a couple of media converters)
> interfaces out the front, and 6 gigabit+ backplane interconnects out
> the back (ideally BASE-?X fiber ethernet, for easier testing and fewer
> electrical hastles when interconnecting).
>
> 1 DDR SO-DIMM
>
> 1 Compact Flash slot, with SystemACE.
>
> Which I want to start playing with intrusion detection, anomoly
> detection, and other Gb rate tasks.  But it is still all months away.
>
> In article <3DB811AD.5C574A01@xilinx.com>,
> Austin Lesea   wrote:
>
> >But yes, they work.  And yes, they are inside the Virtex II Pro.  And 
> yes,
> >they do both clock and data recovery on RX and also do TX as they 
> have the 20X
> >multiplier PLLs to do that job.
> >
> >They were designed for the serial backplane business, not the 1G Ethernet
> >business.  There is also the Serial ATA business that is similar (but not
> >really).  There are many projects by folks to see where we fit 
> without any
> >issues (square pegs in square holes), and then we have those 
> applications that
> >folks are interested in working a bit harder to do (square pegs in round
> >holes).
>
>
> Thanks.  Thats what I was starting to figure:
>
> 1000BASE-?X is fiber, true serial, send and receive, so its simply a
> matter of using a transceiver.  Xilinx tested.  Ony difference between
> flavors being fiber (multimode vs singlemode), frequency, and range.
>
> 1000BASE-T is funkier, with 4 pair signaling and other funky stuff, so
> it would require substantial external ICs.  At which point, just go
> with external MAC/PHY chips.



Article: 48811
Subject: Re: Xilinx POS Power On Surge Current
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 24 Oct 2002 13:48:39 -0700
Links: << >>  << T >>  << A >>

--------------E2425FD9CBDECE09C555ECEF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jim,

The current begins at ~ 2 * Vt (or about 0.7Vdc to 0.9 Vdc) and is all gone at
that value plus another 200 mV.

If you use a limit supply (ie 500 mA min for commercial) the voltage may plateu
there for a few ms, and then it will continue to power on (worst case).  If more
current is available, the device will use it, and power on faster.  Small devices
have a peak current that lasts a few hundred microseconds.  Largest parts have a
peak that lasts less than 3 milliseconds.  The peak is about the same for a small
part, or a large part (hence the confusion about why is the current the same? --
it is, but the time is 30X less).  The peak is so short it has no effect on
reliability, and as it is every single memory cell driving some circuits that is
the source of the current, no single circuit has even 10% of its rated normal
load.

If you try to ramp faster than 2 ms, it will want more current, but 500 mA would
still work (because the ramp wouldn't happen while limiting).  Longer than 50 ms
is not an issue, but we don't test it there, so we don't advocate people using it
there (as it is "terra incognita" because 100% of all devices are tested at < 2ms,
and 50 ms at both 25C and 85C).

Don't think that if you slow the ramp rate it takes less than 500 mA.  A few parts
might, but not all that might be shipped to you (they vary).  Previously there
were appnotes that indicated the current is less with slower ramps, this was not
found to be true in all possible cases.

Where people get into trouble is that they use regulators that trip, or fold back,
and the device will trip or foldback such a regulator pretty well (a non-linear
supply connected to a non-linear load may have more than one stable state - one of
them unwanted).

Xapp158 states that the trip or foldback should be delayed by 20 ms to prevent the
supply from stopping before it gets started to cover the small spike of current.
Of course, during that 20 ms, the supply still must meet the min current
requirement (500 mA in the example above).

As I have said before, this issue is gone from Virtex II and II Pro, as we
redesigned the entire start-up of the architecture to remove this effect.  This
was a major change, and could not be put back into Virtex, Virtex E, Spartan II,
or Spartan IIE.  Spartan IIE was redesigned to reduce the worst case peak by ~>
30%, as well as some other improvements.

Devices in parallel don't exactly require their current at exactly the same
voltage and time, so two devices will power up with as much current as one (or at
least we haven't found two such well matched bad actors), but the spec really does
imply that you have the min current for each part.  I suspect in 100K quantities
of a pcb design, one would see a few pairs of devices that would need more than
one does.

Nothing you do with any pin changes the behavior, as the logic isn't even logic
yet at ~ 2 * Vt.

Austin

Jim Granville wrote:

> MikeJ wrote:
> >
> > oops, that will teach me to make comments here after a few drinks !
> > I tried to make two points, and failed to make either.
> >
> > 1) During the power up sequence the supplies must come up monotonically and
> > stabilise within ~ 50ms. I have not had any problems here, even though I
> > have a lot of decoupling on each device, as the dc-dc converters providing
> > vcc_int current limit ok to a high value.
> >
> > 2) During configuration, and just after, I believe you get quite large but
> > short duration current demands ( 3 - 5 A). However the 'mid range' bulk tant
> > or big ceramic caps I place under the device on each corner supply this
> > need. I also configure the devices one at a time to ease the pain on the
> > supply. comments ?
>
>  I believe the peak is BEFORE config, and occurs at that Vcc where all
> the
> P and N fets do not drive enough to be 'hard digital', but Vcc is high
> enough
> for conduction to start. Can be uA per fet, but multiply that by all the
> FETS....
>
>  What is needed, is a curve trace of Icc / Vcc for a choice of Slew
> rates,
> and with some current limits on Vcc.
>
>  A spice model of the effect would also be good :)
>
>  A key issue is, with ?? current limit, does it just take
> 'longer to get over the hump', or can the Vcc stall permanently.
>
> -jg



Article: 48812
Subject: Re: Silly Virtex 2 Pro question...
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 24 Oct 2002 13:50:24 -0700
Links: << >>  << T >>  << A >>
Ray,

That is the magic issue isn't it?  SONET/SDH has the same pesky issue:  jitter generated
has to be incredibly tiny.  Hard to do even in a dedicated device with an external SAW
resonator.

Austin

Ray Andraka wrote:

> Generated.
>
> Austin Lesea wrote:
>
> > Ray,
> >
> > Jitter generated, or jitter tolerated?
> >
> > If this is jitter tolerated, it might meet the spec (we just haven't tested to it).
> >
> > Austin
> >
> > Ray Andraka wrote:
> >
> > > One of the places I was hoping to use them was for SMPTE-292 HDTV serial
> > > transmission, which is 1.485 Gbps.  Unfortunately it looks like the jitter spec
> > > for the PLL doesn't meet the SMPTE292 specification, so while it can probably be
> > > used, it is not compliant.
> > >
> > > Austin Lesea wrote:
> > >
> > > > Nick,
> > > >
> > > > The MGTs (serdes) in V2 Pro do all of the clock and data recovery on the
> > > > incoming differential pair, and provide the proper transmit serial on its
> > > > output differential pair.
> > > >
> > > > Physically at a minimum you need a transformer for isolation for a four wire
> > > > interface, and an optical to electrical converter for a fiber interface.
> > > >
> > > > There are plenty of other details on the DC balnce of the code, what the bits
> > > > mean, etc. that have to also be taken into account.
> > > >
> > > > But yes, they work.  And yes, they are inside the Virtex II Pro.  And yes,
> > > > they do both clock and data recovery on RX and also do TX as they have the 20X
> > > > multiplier PLLs to do that job.
> > > >
> > > > They were designed for the serial backplane business, not the 1G Ethernet
> > > > business.  There is also the Serial ATA business that is similar (but not
> > > > really).  There are many projects by folks to see where we fit without any
> > > > issues (square pegs in square holes), and then we have those applications that
> > > > folks are interested in working a bit harder to do (square pegs in round
> > > > holes).
> > > >
> > > > As these other applications are made to work reliably, you will see them
> > > > announced.
> > > >
> > > > Since we are using the Connexant serdes IP in Virtex II Pro, we are already
> > > > compatible with their ICs, as well as many other serdes designed for backplane
> > > > and on pcb high speed serial links.
> > > >
> > > > Again, that is the focus of the product.
> > > >
> > > >  http://www.xilinx.com/esp/optical/xlnx_net/oif.htm
> > > >  http://www.xilinx.com/esp/optical/xlnx_net/pci_express.htm
> > > >  http://www.xilinx.com/esp/optical/xlnx_net/xaui.htm
> > > >  http://www.xilinx.com/xlnx/xil_prodcat_landingpage.jsp?title=Aurora
> > > >  http://www.xilinx.com/esp/optical/xlnx_net/fibre_chan.htm
> > > >  http://www.xilinx.com/esp/optical/xlnx_net/inf_band.htm
> > > > etc etc etc
> > > >
> > > > All built in, no extra ICs required.
> > > >
> > > > Austin
> > > >
> > > > "Nicholas C. Weaver" wrote:
> > > >
> > > > > The Xilinx Answer Record states that the RocketI/Os on the V2Pro have
> > > > > been tested and verified to work with 1000BASE-SX (fiber Gb ethernet,
> > > > > multimode fiber).
> > > > >
> > > > > The media for 1000BASE-T however is a 4 pair differential signaling,
> > > > > rather than the serial send/receive of the fiber standards.
> > > > >
> > > > > Are there low cost solutions for driving 1000BASE-T ethernet using the
> > > > > RocketI/Os?
> > > > >
> > > > > --
> > > > > Nicholas C. Weaver                                 nweaver@cs.berkeley.edu
> > >
> > > --
> > > --Ray Andraka, P.E.
> > > President, the Andraka Consulting Group, Inc.
> > > 401/884-7930     Fax 401/884-7950
> > > email ray@andraka.com
> > > http://www.andraka.com
> > >
> > >  "They that give up essential liberty to obtain a little
> > >   temporary safety deserve neither liberty nor safety."
> > >                                           -Benjamin Franklin, 1759
>
> --
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
>
>  "They that give up essential liberty to obtain a little
>   temporary safety deserve neither liberty nor safety."
>                                           -Benjamin Franklin, 1759


Article: 48813
Subject: Re: Silly Virtex 2 Pro question...
From: Ray Andraka <ray@andraka.com>
Date: Thu, 24 Oct 2002 21:23:46 GMT
Links: << >>  << T >>  << A >>
Your question, however made me realize that it doesn't stop one from making a receiver in
the V2pro.  In fact, with that tight spec on the transmitted jitter, it should work quite
nicely in  a receive only application.  Any shot of meeting these really tight jitter specs
in future iterations?  I have to wonder if the early transmitter chips like the AMCC 8501
met the jitter spec or not.

Austin Lesea wrote:

> Ray,
>
> That is the magic issue isn't it?  SONET/SDH has the same pesky issue:  jitter generated
> has to be incredibly tiny.  Hard to do even in a dedicated device with an external SAW
> resonator.
>
> Austin
>
> R--

--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 48814
Subject: Re: Serial PROM Configuration
From: Petter Gustad <newsmailcomp3@gustad.com>
Date: Thu, 24 Oct 2002 22:00:09 GMT
Links: << >>  << T >>  << A >>
"Sanjay Patil" <sanjay@cg-coreel.com> writes:

> But one of XILINX apllication note says PROM3 gets programmed first then
> PROM 2 and finally PROM1.  I am not understanding how this will happen.
> Please give some explanation on how exactly Bitstream file gets programmed
> to Multiple PROMS.

I've done this using mcs files. I take the bitsream file and generate
the mcs using promgen:

promgen -c -w -p mcs -x xc18v04 xc18v04 -u 0 mychip.bit

This will result in two prom files named mychip_0.mcs and
mychip_1.mcs. You can then use impact to program the proms (or to
generate svf files for some other jtag programmer). You can then
program the proms in any order you like. I prefer to make batch files
for impact. Lets say that mychip.imp contains:

setMode -bscan
setCable -port ttyb
addDevice -p 1 -sprom xc18v04 -file mychip_0.mcs
addDevice -p 2 -sprom xc18v04 -file mychip_1.mcs
program -p 1 -erase -verify
program -p 2 -erase -verify
quit

Then you can run:

impact -batch mychip.imp

to program your proms (assuming you have a MultiLinx on ttyb). You
could of course interchange the two program statements to program them
in the opposite order. Expanding this to 3 18v04's should be easy.

If you have other devices in your jtag chain you need to add the bsdl
files in their respective position for these using the addDevice
statement.

If you are using an older software release you'll have to use jtagprog
instead of impact. The syntax of the batch file and program options
will be different.

Petter
-- 
________________________________________________________________________
Petter Gustad         8'h2B | ~8'h2B        http://www.gustad.com/petter

Article: 48815
Subject: Re: Quartus LogicLock problem
From: "Xanatos" <fpsbb98@yahoo.com>
Date: Thu, 24 Oct 2002 22:05:50 GMT
Links: << >>  << T >>  << A >>
Hi Stephen,

I've had problems simular to what you have. One thing I suggest is that you
put in the hierarchy=hard tag into Leonardo around the top level modules.

The other problem that you may have with the carry chains is some
combinational signal that is the output of one module going into another.
Older version of Quartus did not allow that. Make sure your outputs are
registered.

Cheers,
Xanatos

"stephen" <stephen.busch@web.de> wrote in message
news:6643d19f.0210240712.62595be2@posting.google.com...
> Hi,
>   I'm using the LogicLock design flow to incrementally place and route
> a design on a APEX1500KE device. Several people work on the project
> and I
> need to automate the compilation flow, so everything is done with tcl
> scripts.
>
>   I followed the instructions from Altera but I still have some
> problemes. The structure of the design is something like this :
>  top +-- A
>      |   +--- AA
>      |   +--- AB
>      |        +---ABA
>      |        +---ABB
>      +-- B
>      |   +--- BA
>      |   +--- BB
>      |        +---BBA
>      |        +---BBB
>
> Here is what I do :
>   . I generate a edf file for each module (AA, BA, ABA, ABB, BBA, BBB)
>     with Leonardo.
>   . I run quartus for each submodule (AA, BA, ABA, ABB, BBA, BBB) to
>     generate the esf and vqm files. Each submodule contains one or
> more
>     LogicLock regions.
>   . to generate the esf and vqm file of bloc AB I use the vqm and esf
> files
>     generated for ABA and ABB plus an additional edf file. To enforce
> the
>     hierarchie I use the LL_PARENT assignment. I change this
> assignment
>     after importing the lower level .esf files, otherwise it doesn't
> work.
>   ...
>   . for the final place and route I use the files A.vqm A.esf B.vqm
> B.esf and
>     top.edf. The LogicLock regions defined are visible and have the
> correct
>     size at the top level. The position is chosen automaticly by
> quartus
>     for the moment.
>
> For the lower levels everything is fine but I get some problems at the
> top
> level. I get a lot of messages like the one :
>   Warning: Ignored back-annotated location assignment on node
>
bmicro:bmicro_inst|i2c:i2c_enabled_i2c_inst|i2c_intermediaire:i2c_intermedia
ire_inst|i2c_reste:reste|modgen_eq_445_ix46~I_I
> assigned to LogicLock region
> i2c_i2c:i2c_enabled_i2c_inst_bmicro:bmicro_inst because location is
> outside region boundaries
> How could this happen ? At the lower levels all the cells where inside
> the
> logiclock region and I didn't get the message. For the moment I didn't
> try
> to move manually the regions.
>
> Quartus also complains about carry chains it couldn't place inside a
> low level
> logiclock region. But I didn't get this message when it fitted this
> region or
> the next higher level.
>
> My next problem is that I need to chose the position of the logiclock
> regions
> because of timing issues. I can do this using the quartus gui but I
> want to
> move them from a tcl script. When I only change the LL_ORIGIN
> assignment
> the LL_LOCATION assignments aren't updated. Does anyone know which
> command
> I need to run ?
>
> thanks for you help
> stephen



Article: 48816
Subject: Re: Pin locking Virtex 2 FPGA
From: Ray Andraka <ray@andraka.com>
Date: Thu, 24 Oct 2002 22:13:12 GMT
Links: << >>  << T >>  << A >>
Virtex2's bottle neck for speed is typically in the carry chains, which you are
likely using in the counter/timer.  There, you'll want to register the inputs to
the carry chain and place those registers immediately adjacent to the carry
chain.  A 24 bit counter timer is going to put you right at the edge at 200 MHz
in a -4 part.   The fabric itself is capable of well beyond 200 MHz if the carry
chains are not in the critical path.  If you are registering the IOBs, then pin
placement is not supercritical, although you'll still want to keep them at least
near where you are using them.  With unregistered IOBs, pin placement is
critical at these speeds.  Be aware that the current routing software picks the
critical paths and routes to them leaving the ones it deems not critical to
last.  It basically only tries hard enough to meet your constraint and no harder
(it will often forgo the obvious direct connects), so it may not be obvious
where the real speed limits are.



Theron Hicks wrote:

> Mike,
>     Just my experience, but for what it is worth...
> I have been working on a design based on the Spartan2E series chip.  The
> FPGA is composed of a high spped timer counter, some serial d/a and a/d
> signals and some other random i/o.  The FPGA is being pushed in terms of
> speed (200 MHz internal clock, 100 MHz external clock) but not in terms of
> being full (less than 50% utilization).  Tying down my I/O signals myself in
> a somewhat inteligent fashion improved the timing results substantially
> compared to the locations randomly picked by ISE.  By the way, floorplanning
> did not have nearly the impact on speed that locking i/o pins did.
> Re-adjusting my picked locations to improve the "layout-ability" of the
> circuit board did not substantially damage the timing of the circuit.
> Remember that this circuit required speed but was not highly complex and did
> not fill the chip beyond about 50%.  I suspect that complex interaction
> between portions of the circuit and/or high circuit utilization (in terms of
> CLBs used) might likely cause problems with the circuit's maximum clock
> speed.
>
> Theron Hicks
>
> "M Schreiber" <mschreiber75@yahoo.com> wrote in message
> news:e8caa675.0210240939.389b197f@posting.google.com...
> > Hello,
> > I am in the process of a new design.  The design is probably about 50%
> > complete.  All of the interfaces are defined to and from the chip but
> > the internal fpga logic is not completely defined.  Now I need to
> > start the PCB design effort, and lock down some pins.  I ran my design
> > in its current state through the Xilinx tool set and had it choose the
> > pins for me.  Then I went back and glanced over the .ucf file and a
> > few things stood out as less than optimal (at least seems that way to
> > me).  There are many buses throughout the design and I would have
> > expected them to be grouped in a similar area of the chip, but they
> > were not.  The tools did manage to put all of my input clocks on
> > global clock buffers and even a good portion of output clocks to other
> > devices.  I guess the question I am asking is what are some good rules
> > of thumb (I know that these rules can't always be applied) for
> > choosing pin configurations before a design is complete?  Should I let
> > the tools choose most of my pins and modify that list or should I
> > group buses together with timing constraints, etc?  I glanced through
> > comp.arch.fpga for similar topics, but most of them were old and I was
> > wondering if anyone had any new thoughts on the subject.  This is my
> > first major design that I am doing on my own (Xilinx Virtex 2
> > xc2v1000fg456, vhdl based, fpga express, xilinx 4.2i tools) and I want
> > to make sure I do all I can to optimize my design.
> > Thanks,
> > Mike Schreiber
> > Hardware Engineer
> > Mschreiber75@yahoo.com

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 48817
Subject: Re: Pin locking Virtex 2 FPGA
From: Ray Andraka <ray@andraka.com>
Date: Thu, 24 Oct 2002 22:16:40 GMT
Links: << >>  << T >>  << A >>
This depends.  The carry chain in the -4 virtexII is slightly slower than the
carry chain in the virtexE-6.   The virtex E still gives more bank for the buck
in many of my DSP applications.  The virtex2 routes and LUTs are faster, but the
carry chain is not.

MikeJ wrote:

> IVirtex2's are faster than 2e's, and unless you wish to go > 150 Mhz, or have
> some combinatorial paths, you will be fine.
>

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 48818
Subject: Re: Silly Virtex 2 Pro question...
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 24 Oct 2002 15:27:03 -0700
Links: << >>  << T >>  << A >>
Ray,

Receive is just fine, even easier with less TX jitter.

In order to meet the stringent TX jitter one has to use a resonator with a high enough Q to get
low phase noise (the main root cause of jitter in a PLL).

High Q resonators are something not compatible with standard IC processing (ie either impossble
or expensive).  That is why most folks use external resonators with their chips to perform the
task.  SAW resonators are commonly used, as their Q's are in the 1,000's to the 10,000 range,
which is what is required.

So, if the chip uses an external resonator, then it is possible for it to meet the
specification.  Of course, there are many mistakes one can make in the chip to not meet the
specification, so a good characterization report is always required from the vendor.

So if someone announes a really high Q resonator that is compatible with CMOS process and
doesn't take up any area, then you can be sure a lot of folks will use it.


One way to make TX jitter spec easier to 'meet', is to specify it in a frequency band (ie from
20 Hz to 300 KHz).  This way the total jitter power can be (or is) larger, but if we only care
about frequencies that the receiver can track, we can band limit and measure a smaller number.
The jitter in any band-limited measurement leaves open the possibility that if someone
implements a receiver, or transmitter slightly differently, then the resulting link may break.
Both sides meet the 'specification', but they both "cheated" to get there, and actually don't
work (happened to me in fiber optics and telecom years ago).

So, I would warn people to ask for TX jitter unfiltered, peak to peak, just to see everything,
and compare those numbers.  And the peak to peak jitter tolerance vs frequency for the input
(if that is a concern).  After all, it is the peak to peak jitter than causes the errors, and
the error didn't care about its jitter spectral content.

Then you can look as the filtered RMS numbers, which are more pleasant to look at, and you can
compare data sheets to look like you are busy doing something useful (which you are not).

Again, a good characterization report will have all of this useful information.

Austin

Ray Andraka wrote:

> Your question, however made me realize that it doesn't stop one from making a receiver in
> the V2pro.  In fact, with that tight spec on the transmitted jitter, it should work quite
> nicely in  a receive only application.  Any shot of meeting these really tight jitter specs
> in future iterations?  I have to wonder if the early transmitter chips like the AMCC 8501
> met the jitter spec or not.
>
> Austin Lesea wrote:
>
> > Ray,
> >
> > That is the magic issue isn't it?  SONET/SDH has the same pesky issue:  jitter generated
> > has to be incredibly tiny.  Hard to do even in a dedicated device with an external SAW
> > resonator.
> >
> > Austin
> >
> > R--
>
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
>
>  "They that give up essential liberty to obtain a little
>   temporary safety deserve neither liberty nor safety."
>                                           -Benjamin Franklin, 1759


Article: 48819
Subject: Re: Xilinx POS Power On Surge Current
From: "MikeJ" <pacman@fpgaarcade.com>
Date: Fri, 25 Oct 2002 00:12:33 +0100
Links: << >>  << T >>  << A >>
Thanks for the clarification chaps !
On the card I am looking at (18 x v300e's) , I do see some large spikes on
the power rails during JTAG config - this must be originating elsewhere
then. I shall try and get some measurements.
However, it always starts up and configures reliably though, so not too
concerned !

Cheers,
MikeJ

"Peter Alfke" <peter@xilinx.com> wrote in message
news:3DB8485C.8D2815D5@xilinx.com...
>
>
> MikeJ wrote:
>
> > <snip>
> > 2) During configuration, and just after,
>
> No, it is only during power-on, before the beginning of configuration,
that you
> get the extra current. Once configuration has started, you as a user
affect the
> (much smaller) current by the clock rate, first CCLK, later user clock(s).
>
> Peter Alfke
>
>



Article: 48820
Subject: Re: Pin locking Virtex 2 FPGA
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Fri, 25 Oct 2002 00:25:04 +0100
Links: << >>  << T >>  << A >>
MikeJ wrote
> agree totally - the carry chains are a bit of a disappointment. (I had to go
> to -5 speed grade in the 3000, although mainly for the slightly faster
> multipliers).
> I would consider a 24 bit counter to be pushing it at 200 Mhz operation in
> either device !
> Back of the envelope calculation says Virtex2 are 1.5x cost per lut more
> than Virtex E. ??
> Unless I need the bigger block rams or the multipliers I still go for virtex
> E-6, 100 Mhz core clock without any real problems.

Maybe the faster general purpose routing in the V2 could save
your life if the design develops in an unexpected direction
and the beautiful initial floorplan grows a barnacle or two...





Article: 48821
Subject: Re: Pin locking Virtex 2 FPGA
From: "MikeJ" <pacman@fpgaarcade.com>
Date: Fri, 25 Oct 2002 00:30:09 +0100
Links: << >>  << T >>  << A >>
Hi Ray,

agree totally - the carry chains are a bit of a disappointment. (I had to go
to -5 speed grade in the 3000, although mainly for the slightly faster
multipliers).
I would consider a 24 bit counter to be pushing it at 200 Mhz operation in
either device !
Back of the envelope calculation says Virtex2 are 1.5x cost per lut more
than Virtex E. ??
Unless I need the bigger block rams or the multipliers I still go for virtex
E-6, 100 Mhz core clock without any real problems.

However, I was stressing that you should think about the pcb layout and the
device pinout as well, otherwise it might not work at all.

One mistake I made a few years ago was to put a 64 bit bus on one side, and
the reset / control strobes on the other side (accidentally). That was a
total bugger, as it took several ns to get the read enable across the die
from the input register, then the 3-4 ns clock2out of the block ram.
However, I had to place the block rams near the data bus, otherwise the
write side timing failed.
One learns !

Cheers,
MikeJ

"Ray Andraka" <ray@andraka.com> wrote in message
news:3DB87064.181FD533@andraka.com...
> Virtex2's bottle neck for speed is typically in the carry chains, which
you are
> likely using in the counter/timer.  There, you'll want to register the
inputs to
> the carry chain and place those registers immediately adjacent to the
carry
> chain.  A 24 bit counter timer is going to put you right at the edge at
200 MHz
> in a -4 part.   The fabric itself is capable of well beyond 200 MHz if the
carry
> chains are not in the critical path.  If you are registering the IOBs,
then pin
> placement is not supercritical, although you'll still want to keep them at
least
> near where you are using them.  With unregistered IOBs, pin placement is
> critical at these speeds.  Be aware that the current routing software
picks the
> critical paths and routes to them leaving the ones it deems not critical
to
> last.  It basically only tries hard enough to meet your constraint and no
harder
> (it will often forgo the obvious direct connects), so it may not be
obvious
> where the real speed limits are.
>
>




Article: 48822
Subject: Re: LVDS standard
From: Brijesh <brijesh_spamNot@vt.edu>
Date: Fri, 25 Oct 2002 00:44:41 GMT
Links: << >>  << T >>  << A >>
I had question too.
Can we mix LVTTL and LVDS buffers in the same bank?
The documentation doesn't mention anything against it, but it doesn't mention that it can be done also.
I guess, since LVDS does not require Vref, we can mix LVTTL and LVDS, right?

Thanks
Brijesh

hiro wrote:
> Dear all,
> 
> I have a question on Xilinx Virtex2 LVDS buffer.
> The device has two voltage types of LVDS output buffer
> that is OBUF**_LVDS**_33 and OBUF**_LVDS**_25.
> The suffix 33 and 25 show Vcco values(3.3V and 2.5V respectivly)
> 
> What is the difference between them and do the both buffers fit in
> AC/DC characteristics of LVDS standard?
> (The only difference is the value of Vcco and I don't need to consider
> which should be used in corresponding to LVDS standard??)
> 
> I would appreciate hearing replies.
> 
> Sincerely,
> 
> Hiro     


Article: 48823
Subject: Re: Pin locking Virtex 2 FPGA
From: Brijesh <brijesh_spamNot@vt.edu>
Date: Fri, 25 Oct 2002 00:52:37 GMT
Links: << >>  << T >>  << A >>
I got question regarding pin locking.

Assume we have a 4 bit control bus (registered) going out of FPGA.
Is it good to lock 4 I/O pins in a single tile or is good to spread them over 4 tiles?
Since each tile (with 4 IOB's) shares routing resources.

Thanks
Brijesh



M Schreiber wrote:
> Hello,
> I am in the process of a new design.  The design is probably about 50%
> complete.  All of the interfaces are defined to and from the chip but
> the internal fpga logic is not completely defined.  Now I need to
> start the PCB design effort, and lock down some pins.  I ran my design
> in its current state through the Xilinx tool set and had it choose the
> pins for me.  Then I went back and glanced over the .ucf file and a
> few things stood out as less than optimal (at least seems that way to
> me).  There are many buses throughout the design and I would have
> expected them to be grouped in a similar area of the chip, but they
> were not.  The tools did manage to put all of my input clocks on
> global clock buffers and even a good portion of output clocks to other
> devices.  I guess the question I am asking is what are some good rules
> of thumb (I know that these rules can't always be applied) for
> choosing pin configurations before a design is complete?  Should I let
> the tools choose most of my pins and modify that list or should I
> group buses together with timing constraints, etc?  I glanced through
> comp.arch.fpga for similar topics, but most of them were old and I was
> wondering if anyone had any new thoughts on the subject.  This is my
> first major design that I am doing on my own (Xilinx Virtex 2
> xc2v1000fg456, vhdl based, fpga express, xilinx 4.2i tools) and I want
> to make sure I do all I can to optimize my design.
> Thanks,
> 	Mike Schreiber
> 	Hardware Engineer
> 	Mschreiber75@yahoo.com


Article: 48824
Subject: Re: Who has some Lecture materialson I2C Bus?
From: russelmann@hotmail.com (Rudolf Usselmann)
Date: 24 Oct 2002 19:30:31 -0700
Links: << >>  << T >>  << A >>
"Soul in Seoul" <Far@East.Design> wrote in message news:<3db74e36@news.starhub.net.sg>...
> Hi,
> 
> I went to yahoo for "Lecture I2C Bus" and it returned me a bunch of french
> websites.
> Has anyone seen a good decent lecture notes on I2C bus?
> 
> Thanks.

There is a free I2C IP core on OpenCores.org. Perhaps it's
source code and documentation will help you ?

Cheers,
rudi
------------------------------------------------
www.asics.ws   - Solutions for your ASIC needs -
FREE IP Cores: http://www.asics.ws/free_ip.shtml



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