Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
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 TreselerArticle: 48801
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
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
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
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. -jgArticle: 48805
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
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> AEArticle: 48807
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 AlfkeArticle: 48808
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: 48809Ray 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
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
--------------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. > > -jgArticle: 48812
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, 1759Article: 48813
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"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/petterArticle: 48815
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 > stephenArticle: 48816
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
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: 48818Ray, 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, 1759Article: 48819
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
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
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
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, > > HiroArticle: 48823
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.comArticle: 48824
"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:
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