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
On 23 Mar 2006 06:22:37 -0800, "GaLaKtIkUs™" <taileb.mehdi@gmail.com> wrote: >Can you indicate me such a SERDES. It's perfect if its output is >64bits. Also it shoulden't do FEC stuff. FEC is planned to be done on >FPGA. Most 10Gb/s SERDES parts seem to have 16 bit interfaces, probably because there's common interface definition called SFI-4 that has 16 LVDS pairs clocked at 622-670MHz. Xilinx has an app note called XAPP 622 that describes how to implement such an interface on an FPGA. Did you use Google? You would have found SERDES manufacturers such as PMC, AMCC, Broadcom, etc. >Thnaks in advance >Mehdi Thanks for the top-post! > >Allan Herriman wrote: >> On 21 Mar 2006 09:08:21 -0800, "Alain" <no_spa2005@yahoo.fr> wrote: >> >> >Unfortunately, even OC-192 is excluded form Virtex- 4 (ug076.pdf : >> >"Payload compatible only"), so no hope for OTU-2 I think. >> >We have to wait Virtex-5 family ? >> >> No. That is unlikely to have sufficient jitter performance, due to >> certain compromises that must be made when putting an MGT on an FPGA. >> In particular, it's likely to use a ring oscillator rather than an LC >> oscillator which would have better perfomance. >> >> Use an external SERDES designed for G.707 / G.709 work. >> >> Note that (before they discontinued it) Xilinx's standalone SERDES >> didn't meet the SONET jitter requirements either, so getting these >> things to work is clearly not a trivial task. >> >> Regards, >> AllanArticle: 99401
Hi John, If you don't trust the timing constraints, you can use FPGA editor's 'Directed Routing' feature to tie down your net. Either pick a routed configuration that meets your spec., or hand route the net in FPGA editor. Select the net, then go to Tools -> Directed Routing Constraints. You can use the dialogue box to save some text to paste into your UCF file which will route the net you selected the same way every time. You can even have it make relative constraints. It turns out that Xilinx use this themselves in some of their IP products, so it has a fair chance of continuing to work with new software releases! HTH, and good luck! Syms.Article: 99402
At long last I have updated the Pacman release on www.fpgaarcade.com All ROMs are now internal, and RAMB16s are supported by the binary to VHDL program RomGen. General tidyup and simplified clocking scheme. Files generated by RomGen will also now simulate with the Xilinx Unisim simulation library. Download, unzip, then from a DOS command prompt run build_roms.bat and then buils_xst.bat If you are using a different O.S. you are probably capable of writing your own scripts ... Note, no original ROMs are included in this distributions, the included binaries are from a Pong game written by David Widel which runs on Pacman hardware. /MikeJArticle: 99403
Austin, I thought AC termination only worked with 50/50 duty cycle clocks? you got it going with TMS ? I have always used an up/down resistor terminator and lived with the static power dissipation that implies. One thing we did do a while ago was replace the JTAG chain (18 VirtexE devices per board) with a cpu bus interface CPLD which wired directly to the din / cclk pins of each device - programmed 18 different designs in parallel, much faster ... /MikeJ "Austin Lesea" <austin@xilinx.com> wrote in message news:dvuncg$as422@xco-news.xilinx.com... > One more thing, > > We also AC terminate at the endpoints of TMS and TCK. > > This was also shown to be necessary in the simulations. > > But don't just assume this is the "solution", you must simulate your pcb, > and decide what to do. > > Austin >Article: 99404
Mikej,
What I am referring to here, is a cap in series with a 50 ohm resistor
to ground across the input at the end of the line.
signal ------------input
|
cap
|
50ohms
|
ground
This is less static power than a 100 ohm split from power to ground, and
is equivalent (if you really are 50/50) to a 50 ohm resistor to Vcco/2
(also another perfectly accptable termination).
Austin
MikeJ wrote:
> Austin,
>
> I thought AC termination only worked with 50/50 duty cycle clocks? you got
> it going with TMS ?
>
> I have always used an up/down resistor terminator and lived with the static
> power dissipation that implies.
>
> One thing we did do a while ago was replace the JTAG chain (18 VirtexE
> devices per board) with a cpu bus interface CPLD which wired directly to the
> din / cclk pins of each device - programmed 18 different designs in
> parallel, much faster ...
>
> /MikeJ
>
> "Austin Lesea" <austin@xilinx.com> wrote in message
> news:dvuncg$as422@xco-news.xilinx.com...
>
>>One more thing,
>>
>>We also AC terminate at the endpoints of TMS and TCK.
>>
>>This was also shown to be necessary in the simulations.
>>
>>But don't just assume this is the "solution", you must simulate your pcb,
>>and decide what to do.
>>
>>Austin
>>
>
>
>
Article: 99405Austin Lesea wrote: <snip> > > AMIS: > > FY 2001 2002 2003 2004 2005 > $$ 326M 345M 454M 517M 504M > SA 0 0 96.7M 119M 110.4M Hmmm.... <paste> Austin's earlier claims... > 155M$ is the whole MARKET (IN 2005, ISuppli). That was spread over as many as 12 companies in that year. >LSI had the largest share of that, at 35M$. Everyone one else had a smaller chunk than 35M$. If I read your table above correctly, you have AMIS at $110.4M SA in 2005, but just a few "Austin-Arm-Waves" ago, you had LSI as the Largest player, at $35M ?! Still, I guess it makes for rather less dramatic arm-waving, if it is not _actually_ the largest player that has just exited... ? Shame to let the numbers get in the way of a good spin :) -jgArticle: 99406
johnp wrote: > Austin - > > Thanks for the comments. I'm just frustrated because if I run > multi-pass P&R, the tools can find a solution that meets timing, > but I don't see any hints as to how to use RLOCs to force the > critical cells into magical alignments that produce the smaller > interconnect delay. Since Austin has revealed these are real numbers, could you somehow fine tune the costraints, so the longer paths do not (quite) make the cut ? -jgArticle: 99407
Chris, I have run into a similar problem with the Platform Flash. What you can do is look at a file located in the Xilinx tools directory called C:\Xilinx81\xc18v00\data\xc18v01_pc20_1532.bsd This is the ieee1532 bsdl file that describes the programming algorithm. for the xc18v00. Using this file and an understanding of the JTAG interface, you maybe able to decipher how to program your device. Also it would be usefill to observe the JTAG signals of one of the Xilinx programmers while it is programming a device,. That is if you have access to one. Between the bsdl file, the Xilinx softwaer you spoke of below and observing the JTAG bins I was able to impliment my onw program for the Platform Flash. Good luck Dave "barnhart" <ceb.dideas@gmail.com> wrote in message news:1143031828.217216.43960@i40g2000cwc.googlegroups.com... > Would anyone know where to get the JTAG programming specs (and > programming times, page sizes, etc) for the XC18V01? I'd like to > create an application for re-programming a 18V01 that takes as input > the Intel Hex (MCS) and outputs JTAG bit banging. Xilinx recommends > (app note 58 and 500) generating SVF or XSVF and using the XSVF player > for the JTAG bit-bang. Unfortunately the memory requirements of this > player are excessive. > > So far most of my knowledge has been from studding the SVF file for the > 18V01 that is generated by Impact - however - this isn't a good way to > generate solid foundation for this project - and Xilinx has thus far > been unwilling to provide these specifications. > > TIA, > Chris > > > Section of SVF file that program's a page: > > RUNTEST 1 TCK; > RUNTEST 1 TCK; > // Loading device with a 'faddr' instruction. > SIR 8 TDI (eb) ; > SDR 16 TDI (0060) SMASK (ffff) ; > RUNTEST 1 TCK; > RUNTEST 1 TCK; > // Loading device with a 'fpgm' instruction. > ENDIR IRPAUSE; > SIR 8 TDI (ea) ; > RUNTEST 1 TCK; > RUNTEST 14000 TCK; > // Loading device with a 'fdata0' instruction. > SIR 8 TDI (ed) ; > SDR 2048 TDI > (0100401004010000000000000000000000000004010040100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 > 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 > 0000000000000000000000000000000000) SMASK > (ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff > ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff > ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff) ; > ENDIR IDLE; > > > > XC18V01 BSD documents the following JTAG opcodes: > > Attribute INSTRUCTION_OPCODE of XC1801 : entity is > "BYPASS ( 11111111)," & > "SAMPLE ( 00000001)," & > "EXTEST ( 00000000)," & > "IDCODE ( 11111110)," & > "USERCODE ( 11111101)," & > "HIGHZ ( 11111100)," & > "CLAMP ( 11111010)," & > "ISPEN ( 11101000)," & > "ISPENC ( 11101001)," & > "FPGM ( 11101010)," & > "FADDR ( 11101011)," & > "FVFY0 ( 11101111)," & > "FVFY1 ( 11111000)," & > "FVFY3 ( 11100010)," & > "FVFY6 ( 11100110)," & > "FERASE ( 11101100)," & > "SERASE ( 00001010)," & > "FDATA0 ( 11101101)," & > "FDATA3 ( 11110011)," & > "FBLANK0 ( 11100101)," & > "FBLANK3 ( 11100001)," & > "FBLANK6 ( 11100100)," & > "NORMRST ( 11110000)," & > "CONFIG ( 11101110)," & >Article: 99408
johnp wrote: > Austin - > > Thanks for the comments. I'm just frustrated because if I run > multi-pass P&R, the tools can find a solution that meets timing, > but I don't see any hints as to how to use RLOCs to force the > critical cells into magical alignments that produce the smaller > interconnect delay. > > John Providenza > Ideal placement no longer guarantees an ideal route, sorry to say. In releases before the 5.1 "escape", there used to be a delay based clean-up so that if you gave it a perfect placement, the router did a darned good job of getting the routing correct. Since then however, the router only works as hard as it has to for the whole design to meet timing. The thing is, it no longer picks the low hanging fruit (ie the direct connects) consistently, which in turn congests the other routing resources. As a result, the router winds up stepping all over itself trying to get something that meets timing; if you are pushing the performance hard, the router will often not be able to find a solution that meets timing in a dense design unless you happened to have the right cost table (MPPR iterates using different cost tables to affect the routing order). In those cases, about your only option, assuming you've already tried setting the router to maximum effort continue on impossible, is to use directed routing...basically hand routing it with the FPGA editor and then exporting the routing info into a ucf. I don't wish that on my worst enemy, as it is a gruelling task if more than a small design or macro.Article: 99409
I have experenced memory leaks with the 8.1 release of the Xilinx tools on two different machines. I mean on the order of 1 gigabyte of lost memory. Has anyone else seen this? DaveArticle: 99410
Hi Austin, I understand what you mean, the reason I used a 100 ohm split (what I refered to as an up/down terminator) is that it always looks like 50 ohms to ground even to non-50/50 signals like TMS. Surely with your cap/resistor terminator (which I use for most of my clocks) it is a 50 ohm to some odd voltage depeding what TMS has been doing recently ? I guess it still functions when TMS changes state, but has the advantage of consuming no power when TMS is stuck high, which of course is almost always. /MikeJ "Austin Lesea" <austin@xilinx.com> wrote in message news:dvvbpb$om31@xco-news.xilinx.com... > Mikej, > > What I am referring to here, is a cap in series with a 50 ohm resistor to > ground across the input at the end of the line. > > signal ------------input > | > cap > | > 50ohms > | > ground > > This is less static power than a 100 ohm split from power to ground, and > is equivalent (if you really are 50/50) to a 50 ohm resistor to Vcco/2 > (also another perfectly accptable termination). > > Austin > > MikeJ wrote: > >> Austin, >> >> I thought AC termination only worked with 50/50 duty cycle clocks? you >> got it going with TMS ? >> >> I have always used an up/down resistor terminator and lived with the >> static power dissipation that implies. >> >> One thing we did do a while ago was replace the JTAG chain (18 VirtexE >> devices per board) with a cpu bus interface CPLD which wired directly to >> the din / cclk pins of each device - programmed 18 different designs in >> parallel, much faster ... >> >> /MikeJ >> >> "Austin Lesea" <austin@xilinx.com> wrote in message >> news:dvuncg$as422@xco-news.xilinx.com... >> >>>One more thing, >>> >>>We also AC terminate at the endpoints of TMS and TCK. >>> >>>This was also shown to be necessary in the simulations. >>> >>>But don't just assume this is the "solution", you must simulate your pcb, >>>and decide what to do. >>> >>>Austin >>> >> >>Article: 99411
Hi All, Does anyone know how to use the embedded carry chain for data muxing. The Picoblaze docs state that it can use the MUXCY for this. I am not sure how to use it for data muxing, if anyone knows, your help will be greatly appreciated. Thanks in advance SudhirArticle: 99412
Sudhir.Singh@email.com wrote: > Hi All, > Does anyone know how to use the embedded carry chain for data muxing. > The Picoblaze docs state that it can use the MUXCY for this. I am not > sure how to use it for data muxing, if anyone knows, your help will be > greatly appreciated. > Thanks in advance > Sudhir > You use the carry chain as a wide OR gate and place an AND in the LUT at each bit. The AND at each bit has to be fed the decoded select on one input and the input bit on the other input. The muxcys get wired with a '1' tied to the DI input and the CI input of the first one in the chain is connected to '0'. One carry chain per bit in your mux, one LUT per carry chain for each mux input. If there are 3 or fewer bits in the select, you can do the decoding right in the LUT. If more than 3 select bits, then you need an external decode or partial decode, which can be shared between mux bits (ie shared among several carry chains).Article: 99413
Ray, Well, the PMCD is just some custom layout flip flops. Nothing more. So jitter on the input side of a FF jitters the Q output in a pretty linear through fashion. Austin Ray Andraka wrote: > Austin Lesea wrote: > >> Bob, >> >> We designed the PMCD so that the outputs all all matched within tens >> of picoseconds across P-V-T. From there, you get onto the BUFGs, and >> you end up with the usual +/-100ps rule for match between BUFgs. >> >> > > Austin, That is basically what I was told when Virtex I came out too, > but it turned out that jitter on the DLL input could cause a spread > between the 1x and 2x clocks (IIRC, I had specifically asked both here > on the NG and through the hotline about the alignment of the 1x and 2x > clocks and whether it was safe to cross clock bounds without extra logic > and was told it was fine. I don't think anyone realized then what > effect jitter would have on the relative phases of the 1x and 2x outputs. > > So my question is, I realize you've designed the PMCDs for tight > tolerances, but how well does that stand up to jitter on the clock input?Article: 99414
On 2006-03-19, adventleaf@gmail.com <adventleaf@gmail.com> wrote: > > when FRAME# is asserted target is expected to latch the Address/Command > respectively. > because after that FRAME# will be de-asserted and DATA/Byte_Enable > follows. For a config cycle you have to look at IDSEL instead. The config read/write commands are different from mem read/write. IDSEL will often be the same as one of the address lines, so you must ignore it when the command is not a config cycle. For an example try: http://www.ben.com/minipci/ Specifically you can see on: http://www.ben.com/minipci/verilog.php the difference between cfg_hit and addr_hit. -- Ben Jackson <ben@ben.com> http://www.ben.com/Article: 99415
JG, Who ya going to believe? AMIS finacial post on their webpage (to the federal governement)? Or some silly market research company that they try get people to buy? I noticed this too. So, is AMIS overstating their Structured ASIC wins to their stockholders and the governement? Shades of Enron? Or is Isuppli using a different definition? Or just doesn't know anything? If this is about < 35M$ vs ~104M$, then I rest my case: structured ASIC is dying...or already dead. What the investors thought they would be seeing is another multi billion dollar market by now. And growth. These numbers (pick any) are just pitiful. AustinArticle: 99416
MikeJ wrote: > Hi Austin, > > I understand what you mean, the reason I used a 100 ohm split (what I > refered to as an up/down terminator) is that it always looks like 50 ohms to > ground even to non-50/50 signals like TMS. > > Surely with your cap/resistor terminator (which I use for most of my clocks) > it is a 50 ohm to some odd voltage depeding what TMS has been doing recently > ? I guess it still functions when TMS changes state, but has the advantage > of consuming no power when TMS is stuck high, which of course is almost > always. You are correct, in so far that it could (in theory) degrade the eye pattern, but adding some history loading on the line - but from a simple reflection/ringing viewpoint, it will work. At 5MHz you are probably not pushing the eye patterns much :) -jgArticle: 99417
Hi I use the following command to generate the .hex file to be programmed promgen -spi -p hex -o promdata.hex -s 2048 -u 0 gl.bit gl.bit is made from the ISE 7.1 This .hex file i program into the SPI flash using the xspi utility downloaded from xilinx. My device is 250e-100VQFP I have got another board with 250e-144TQFP with same SPI interface and that works fine using the same procedure i follow. Any idea ! what is happening ? Is there any Bug in 100-pin package FPGA ? rgds bijoyArticle: 99418
Ray Andraka wrote: > johnp wrote: > >> Austin - >> >> Thanks for the comments. I'm just frustrated because if I run >> multi-pass P&R, the tools can find a solution that meets timing, >> but I don't see any hints as to how to use RLOCs to force the >> critical cells into magical alignments that produce the smaller >> interconnect delay. >> >> John Providenza >> > > Ideal placement no longer guarantees an ideal route, sorry to say. In > releases before the 5.1 "escape", there used to be a delay based > clean-up so that if you gave it a perfect placement, the router did a > darned good job of getting the routing correct. Since then however, the > router only works as hard as it has to for the whole design to meet > timing. The thing is, it no longer picks the low hanging fruit (ie the > direct connects) consistently, which in turn congests the other routing > resources. If a PCB router did this, it would be laughed out of the market... -jgArticle: 99419
Austin Lesea wrote > If you order them, they will arrive. I think that is how it is supposed > to work? > > Sometimes sooner, sometimes on time (and the objective is to never be > late). > > So don't blame us that we delivered an order, please! Yes, I do blame Xilinx. Because the line you give out is that a delivery date cannot be quoted until an order is placed. And if we want to discover the date at which volume will be available, we have to place a large order for delivery ASAP. Are you familiar with Catch-22? I am puzzled by the tone of your response. What I posted was more than amiable, considering the treatment dished out by your distributors (for whom I know you take no responsibility) and you use a public forum to dump your sarcasm on me. That was inappropriate.Article: 99420
Hi Folks, It's been a while since I've needed to do anything fancy with Xilinx timegroups, but I've inherited a design that requires multi-cycle timing constraints. It's a typical scenario, an 80MHz global clock, w/ a 10MHz clock enable active on the 8th phase of a three-bit divide counter. Quoting from the cgd: "You can place TNM on any net in the design. The constraint indicates that the TNM value should be attached to all valid elements fed by _all_paths_that_fan_forward_ from the tagged net. Forward tracing stops at FFS, RAMS, LATCHES, PADS, CPUS, HSIOS, and MULTS." (emphasis mine) After inserting the proper grouping constraint: NET "CE_10MHz" TNM = "TG_10MHz"; # FFs, RAMs, etc that operate w/ 100ns period what I see in Timing Analyzer is that the group TG_10MHz appears to be limited to only elements that are directly on the CE_10MHz net, and combinatorial derivatives ( specifically, conjunctive derivatives, ie. through an "and" function ) seem to be omitted from the group. To me, the phrase "fan forward" in the doc means through combinatorial logic, not just through routing fabric, and my poor old memory recalls that TNM used to work that way. Consequently, when I apply: TIMESPEC "TS_10MHz" = FROM "TG_10MHz" TO "TG_10MHz" "TS_Clk80MHz" * 8; many of the paths that should prioritize into this constraint do not, and are being held hostage to the 12.5 ns master clock period instead of the desired 100ns. Anyone seen anything like this recently? Regards All, Just JohnArticle: 99421
Hello, I would like to access environment variables defined in ModelSim (6.0d) in my Verilog code so that I can use them with the `ifdef construct. For instance, ModelSim allows you to access the "MODEL_TECH" environment variable, which is useful for employing `ifdef's on code you want that you want to be compiled for simulation, but ignored for hardware synthesis. In a similar vein, I tried creating and setting my own environment variable using "setenv MY_VARIABLE 1" in my .do compile tcl script right before the script compiles my modules. Unfortunately, the Verilog code is not able to access this env variable. I'm avoiding using an include file, but if there is not way around this, then that's what I'll have to do. Thanks, NNArticle: 99422
Austin, Tim is right to be p****** 1) sometimes placement of an order depends on the known deliver date 2) if ordered items arrive way too early than you have to pay earlier so speed delivery (before delivery date) may give quite a bit financial problems if money is being used wise. example you know XC3S100E will be delivered W27 so you plan all your actions for the product that uses it in such timeline that money to buy them out will be 'free' for use when the parts arrive, and that the product other components are also purchased at about the same time and production is targetted as well. now if these parts arrive W14 and not W27 then, 1) you will have to pay immediatly 2) the parts will still be laying around til W27 because that when you get PCB this is exactly a story I heard from manufacturer of Xilinx based boards. AnttiArticle: 99423
the 100pin package has 2 different pinouts depending if you have early ES part or production part! check the datasheet and documentation. but the different pins are some Mode pins so if wrong the config would not start I guess, so it might be different issue. AnttiArticle: 99424
Brannon schrieb: > 4. Standard driver interface. Need I say more? How many of you write > directly to the parallel port? All of you? Uh huh, I knew it. I'm sure > you all enjoy it too. How about something like this: There are existing JTAG APIs. Which one becomes a standard is the choice of the developers that use them. Maybe there never will be a widely accepted standard, but that does not matter as mutliple APIs can coexist. - Openwince has a nice iAPI with drivers for quite a lot of interfaces. It is relatively easy to add new drivers. http://openwince.sourceforge.net/jtag/ - Xilinx provides a TCL API. - There is an extremely primitive Java JTAG API from SUN and Xilinx. - Any SVF player can be used to send JTAG commands from an application to the chips. (Openwince also contains an SVF player) Unfortunately the openwince project is rather inactive for a few years now, but maybe we can change that. As far as your other suggestion are concerned: It is important that JTAG stays extremely simple to implement. An FPGA can justify a complex JTAG replacement. But for board testing it can be very important to have bus buffers that have JTAG-ports. I do not want to pay for an IP layer in each of my buffer ics. There exist simple controller ICs that split a JTAG chain in parts that can be individually shifted. That solves virtually all of your other concerns. Kolja Sulimma
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