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
Hi all, I am using virtex 5 (LXT) device in the design. In this, FPGA need to interfaced with copper media 1000BaseT using the core "Ethernet 1000BASE-X PCS/PMA or SGMII". design flow would be "FPGA (MAC -> GMII to SGMII bridge -> GTP transceivers) -> PHY with SGMII support -> 10/100/1000Base -T". Here my question is, In xilinx V5 datasheet DS100.pdf, it is mentioned "Tri-mode 10/100/1000 Mb/s Ethernet MACs - LXT, SXT, TXT, and FXT Platforms - RocketIO transceivers can be used as PHY or connect to external PHY using many soft MII (Media Independent Interface) options": Is it possible to directly connect FPGA to Coppermedia without using the external PHY ? i.e, FPGA(SGMII) to copper media ? Or should the external PHY must always be available in copper media design ? In Datasheet, what Xilinx is referring as " RocketIO transceivers can be used as PHY" ? Note: I am not using 1000BaseX(fiber) in the design. Regards, VijayanArticle: 144101
On Nov 11, 3:57=A0pm, Vijayan <vicchemi...@gmail.com> wrote: > Hi all, > > I am using virtex 5 (LXT) device in the design. In this, FPGA need to > interfaced with copper media 1000BaseT using the core "Ethernet > 1000BASE-X PCS/PMA or SGMII". > design flow would be "FPGA (MAC -> GMII to SGMII bridge -> GTP > transceivers) -> PHY with SGMII support -> 10/100/1000Base -T". > > Here my question is, In xilinx V5 datasheet DS100.pdf, it is mentioned > "Tri-mode 10/100/1000 Mb/s Ethernet MACs > - LXT, SXT, TXT, and FXT Platforms > - RocketIO transceivers can be used as PHY or connect to > external PHY using many soft MII (Media Independent > Interface) options": > > Is it possible to directly connect FPGA to Coppermedia without using > the external PHY ? i.e, FPGA(SGMII) to copper media ? > > Or should the external PHY must always be available in copper media > design ? > > In Datasheet, what Xilinx is referring as " RocketIO transceivers can > be used as PHY" ? > > Note: I am not using 1000BaseX(fiber) in the design. > > Regards, > > Vijayan for copper you need external PHY AnttiArticle: 144102
On Wed, 2009-11-11 at 06:14 -0800, Antti wrote: > On Nov 11, 3:57 pm, Vijayan <vicchemi...@gmail.com> wrote: > > Hi all, > > > > I am using virtex 5 (LXT) device in the design. In this, FPGA need to > > interfaced with copper media 1000BaseT using the core "Ethernet > > 1000BASE-X PCS/PMA or SGMII". > > design flow would be "FPGA (MAC -> GMII to SGMII bridge -> GTP > > transceivers) -> PHY with SGMII support -> 10/100/1000Base -T". > > > > Here my question is, In xilinx V5 datasheet DS100.pdf, it is mentioned > > "Tri-mode 10/100/1000 Mb/s Ethernet MACs > > - LXT, SXT, TXT, and FXT Platforms > > - RocketIO transceivers can be used as PHY or connect to > > external PHY using many soft MII (Media Independent > > Interface) options": > > > > Is it possible to directly connect FPGA to Coppermedia without using > > the external PHY ? i.e, FPGA(SGMII) to copper media ? > > > > Or should the external PHY must always be available in copper media > > design ? > > > > In Datasheet, what Xilinx is referring as " RocketIO transceivers can > > be used as PHY" ? > > > > Note: I am not using 1000BaseX(fiber) in the design. > > > > Regards, > > > > Vijayan > > for copper you need external PHY > > Antti More precisely, for 1000BASE-T you need an external PHY. JanArticle: 144103
Hello all, I have having trouble figuring out how to properly define some timing constraints for an interface between two Xilinx Virtex-4 LX100's. If anybody has any insight on the best way to solve this problem, it would be appreciated. Here are the fixed system parameters (these cannot be changed no matter how much easier it would make the design). 1) Each FPGA is provided with an identical 384 MHz clock. 2) Inside of each FPGA, a PMCD divides the 384 MHz clock down to 96 MHz. 3) There are some control signals which need to be sent back and forth between the FPGAs which are generated in the 96 MHz clock domain. 4) Between the FPGAs there are pins which are connected directly, including 2 pins in each direction which are capable of driving differential clocks if needed. All of these signals are in 2.5 V banks. 5) There is a worst case of 0.95 ns propagation time on the lines between the two FPGAs. The problem is that due to the 96 MHz clock being derived in each FPGA, there is not a defined phase relationship between the two 96 MHz clocks (there could be any one of 4 relative phases), so data can not just be sent back and forth as if it were synchronous. I have tried constraining with OFFSET IN and OFFSET OUT constraints that can handle these 4 relative phases (basically constrain as if it were a 384 MHz clock) but this appears to be too much for the FPGA to handle. Here are the constraints I defined in this case: NET "clk_384mhz_p" TNM_NET "clk_384mhz_p"; TIMESPEC "TS_clk384mhz_p" = PERIOD "TS_clk384mhz_p" 10.4 ns HIGH 50%; NET "outputData<*>" OFFSET = 0.6 ns AFTER "clk_384mhz_p"; NET "inputData<*>" OFFSET = IN 1 ns VALID 1.6 ns BEFORE "clk_384mhz_p"; Another idea I have tried is to use source synchronous design to forward the 96 MHz clock (as a differential clock) with the data and then use a FIFO to move it into the "receiving" 96 MHz clock domain after clocking it in with the "originating" 96 MHz. Once again though, the design has trouble meeting timing. Here are the constraints I defined in this case: NET "clk_384mhz_p" TNM_NET "clk_384mhz_p"; TIMESPEC "TS_clk384mhz_p" = PERIOD "TS_clk384mhz_p" 10.4 ns HIGH 50%; NET "originatingClk_p" TNM_NET ="originatingClk_p"; TIMESPEC "TS_originatingClk_p" = PERIOD "originatingClk_p" 10.4 ns HIGH 50%; NET "outputData<*>" OFFSET = 5 ns AFTER "clk_384mhz_p"; NET "inputData<*>" OFFSET = IN 4 ns VALID 4 ns BEFORE "originatingClk_p"; Does anybody have any insight into the best way to solve this problem? Thanks!Article: 144104
Hello everybody, I am developing a camera with a Spartan3A DSP and a sensor which uses 1.8V LVDS. The Spartan 3A DSP datasheet says that only 2.5 and 3.3V LVDS is supported. The signal rate is 108MHz DDR. Any suggestions what should I do? Specify in UCF LVDS_25 and pray to work OK? It is pretty much the same with a Spartan6. Best regards, AlesArticle: 144105
On Nov 11, 6:27=A0pm, Guru <ales.gor...@gmail.com> wrote: > Hello everybody, > > I am developing a camera with a Spartan3A DSP and a sensor which uses > 1.8V LVDS. The Spartan 3A DSP datasheet says that only 2.5 and 3.3V > LVDS is supported. The signal rate is 108MHz DDR. > > Any suggestions what should I do? Specify in UCF LVDS_25 and pray to > work OK? > It is pretty much the same with a Spartan6. > > Best regards, > > Ales I forgot to mention that transmitter (sensor) swing is typically 150mV (100-200mV) and need 100ohm termination. For termination I planned to use 110ohm IOB termination. Best reagards, AlesArticle: 144106
On Nov 11, 11:38=A0am, Paragon <paragon.j...@gmail.com> wrote: > Hello all, > > I have having trouble figuring out how to properly define some timing > constraints for an interface between two Xilinx Virtex-4 LX100's. =A0If > anybody has any insight on the best way to solve this problem, it > would be appreciated. > > Here are the fixed system parameters (these cannot be changed no > matter how much easier it would make the design). > > 1) Each FPGA is provided with an identical 384 MHz clock. > 2) Inside of each FPGA, a PMCD divides the 384 MHz clock down to 96 > MHz. > 3) There are some control signals which need to be sent back and forth > between the FPGAs which are generated in the 96 MHz clock domain. > 4) Between the FPGAs there are pins which are connected directly, > including 2 pins in each direction which are capable of driving > differential clocks if needed. =A0All of these signals are in 2.5 V > banks. > 5) There is a worst case of 0.95 ns propagation time on the lines > between the two FPGAs. > > The problem is that due to the 96 MHz clock being derived in each > FPGA, there is not a defined phase relationship between the two 96 MHz > clocks (there could be any one of 4 relative phases), so data can not > just be sent back and forth as if it were synchronous. > > I have tried constraining with OFFSET IN and OFFSET OUT constraints > that can handle these 4 relative phases (basically constrain as if it > were a 384 MHz clock) but this appears to be too much for the FPGA to > handle. > > Here are the constraints I defined in this case: > > NET "clk_384mhz_p" TNM_NET "clk_384mhz_p"; > TIMESPEC "TS_clk384mhz_p" =3D PERIOD "TS_clk384mhz_p" 10.4 ns HIGH 50%; > > NET "outputData<*>" OFFSET =3D 0.6 ns AFTER "clk_384mhz_p"; > NET "inputData<*>" OFFSET =3D IN 1 ns VALID 1.6 ns BEFORE > "clk_384mhz_p"; > > Another idea I have tried is to use source synchronous design to > forward the 96 MHz clock (as a differential clock) with the data and > then use a FIFO to move it into the "receiving" 96 MHz clock domain > after clocking it in with the "originating" =A096 MHz. =A0Once again > though, the design has trouble meeting timing. > > Here are the constraints I defined in this case: > > NET "clk_384mhz_p" TNM_NET "clk_384mhz_p"; > TIMESPEC "TS_clk384mhz_p" =3D PERIOD "TS_clk384mhz_p" 10.4 ns HIGH 50%; > > NET "originatingClk_p" TNM_NET =3D"originatingClk_p"; > TIMESPEC "TS_originatingClk_p" =3D PERIOD "originatingClk_p" 10.4 ns > HIGH 50%; > > NET "outputData<*>" OFFSET =3D 5 ns AFTER "clk_384mhz_p"; > NET "inputData<*>" OFFSET =3D IN 4 ns VALID 4 ns BEFORE > "originatingClk_p"; > > Does anybody have any insight into the best way to solve this problem? > > Thanks! I vote for your second approach. Which timing constraint are you having trouble with? For source-synchronous data you don't need to concern yourself with offset output constraints as long as all of your data and clock signals are registered in the IOB's. Use DDR flip-flops for the clock and standard flops for data unless you need DDR rates. Center the active clock edge in the data window. Use the same IO standard for clock and data for lowest skew. At 96 MHz this should give the other end of the link close to 5 ns setup and hold. Regards, GaborArticle: 144107
On Nov 11, 12:45=A0pm, Guru <ales.gor...@gmail.com> wrote: > On Nov 11, 6:27=A0pm, Guru <ales.gor...@gmail.com> wrote: > > > Hello everybody, > > > I am developing a camera with a Spartan3A DSP and a sensor which uses > > 1.8V LVDS. The Spartan 3A DSP datasheet says that only 2.5 and 3.3V > > LVDS is supported. The signal rate is 108MHz DDR. > > > Any suggestions what should I do? Specify in UCF LVDS_25 and pray to > > work OK? > > It is pretty much the same with a Spartan6. > > > Best regards, > > > Ales > > I forgot to mention that transmitter (sensor) swing is typically 150mV > (100-200mV) and need 100ohm termination. For termination I planned to > use 110ohm IOB termination. > > Best reagards, > > Ales LVDS is LVDS regardless of the supply voltage. 1.8V, 2.5V and 3.3V LVDS all have the same common-mode voltage and differential swing. There should be mo problem interfacing these signals to the Spartan 3A. If the Spartan 3A doesn't have integrated differential termination I would suggest using an external resistor rather than burning up internal thevenin termination current. Regards, GaborArticle: 144108
I have over bought 400pcs on the Virtex 5 XC5VLX50-1FFG676C . I will not being using this product anymore and am willing to let them go for $80 each. These are all new in factory original packaging purchased from authorized channels. If you have an interest I will supply pictures and extend terms to credit worthy companies. Jon E. Hansen (949)864-7745 jon@pyramidemail.comArticle: 144109
On Nov 7, 9:53=A0am, Karl Berry <kberr...@gmail.com> wrote: > I'm trying to look into the status of free software/open source > efforts relating to FPGA (because rms asked me to). > > After searching in this group, wikipedia, etc., the one I've been able > to find is slipway/abits from Adam Megacz (Adam, are you still here?), > but from checking out the sources it seems development stalled a while > back, understandably enough since I gathered from the last post I saw > about it that the manufacturer didn't have much interest in the > hardware any more. > > Are there any other ongoing projects? =A0Any info greatly appreciated. > Thanks in advance. > > Karl Berry (karl /at/ gnu /dot/ org) I take it you are interested in full-up synthesis/mapping/P&R tools and not IP. Here are some links to look at, besides the ones already mentioned in this thread: http://www.verilog.net/free.html http://sourceforge.net/projects/signs/ http://www-labsticc.univ-ubs.fr/www-gaut/ As far as the core optimization/tech mapping goes, there is ABC from Berkeley http://www.eecs.berkeley.edu/~alanmi/abc/ and there is VPR from UToronto for place and route http://www.eecg.utoronto.ca/vpr/ It would be good to have an open source stack to take in a language(Verilog,VHDL,C,SystemC,...) and produce an RTL subset that is like a universal assembly language and that goes into the X&A toolsets for device specific mapping, optimization, place&route and bitstream generation. alanArticle: 144110
On Nov 10, 5:17=A0am, Curt Johnson <curt.john...@dicombox.net> wrote: > malcolm wrote: > > Err, but a random-deleted net is actually easy to find, as you usually > > have more than one copy (as in, in the SCH, or even in a copy of the > > PCB ) ? > > > Which Mentor flows/versions are you using ? > > If I have plots from an earlier revision, I compare them with the new > revision one page at a time on a light box. Every difference has to be > traced to ensure that it is an intended change. > > On a 10 layer PCB with 4 BGAs, about a dozen smaller packages and a > couple of hundred discretes, it takes me two or three days. > > Not difficult, but extremely tedious. yes, that I can believe... However, PADS does allow an ASCII compare, which will do that comparison in seconds ?. You can also safely re-import a netlist at any time, and it simply skips existing pin pairs, and will add any missing ones, which will stand out as unrouted. ASCII export/import also checks your database integrity, as it rebuilds the design. DXF does the same. You can also generate reports that count pin pairs/nets etc.. Or, if you want a more modern lightbox, we use GerbView: http://www.softwarecompanions.com/gbupdate.html This will export layered PDFs, and import multiple gerbers, and is is low cost. Works well with PADS. > > Viewdraw & Pads. I'm using Viewdraw (or DxDesigner I think they call it > now) version 2006.1. I havn't been able to get the 2007 release to read > in any of our current projects. > > The random net deleting feature has been in place since before I started > here in 1993; but before BGAs, we could always rework the boards. Is it Viewdraw, or Pads that drops the info ? Is this a whole net, or a pin-pair ? -jgArticle: 144111
On Nov 11, 1:25=A0pm, Gabor <ga...@alacron.com> wrote: > On Nov 11, 11:38=A0am, Paragon <paragon.j...@gmail.com> wrote: > > > > > > > Hello all, > > > I have having trouble figuring out how to properly define some timing > > constraints for an interface between two Xilinx Virtex-4 LX100's. =A0If > > anybody has any insight on the best way to solve this problem, it > > would be appreciated. > > > Here are the fixed system parameters (these cannot be changed no > > matter how much easier it would make the design). > > > 1) Each FPGA is provided with an identical 384 MHz clock. > > 2) Inside of each FPGA, a PMCD divides the 384 MHz clock down to 96 > > MHz. > > 3) There are some control signals which need to be sent back and forth > > between the FPGAs which are generated in the 96 MHz clock domain. > > 4) Between the FPGAs there are pins which are connected directly, > > including 2 pins in each direction which are capable of driving > > differential clocks if needed. =A0All of these signals are in 2.5 V > > banks. > > 5) There is a worst case of 0.95 ns propagation time on the lines > > between the two FPGAs. > > > The problem is that due to the 96 MHz clock being derived in each > > FPGA, there is not a defined phase relationship between the two 96 MHz > > clocks (there could be any one of 4 relative phases), so data can not > > just be sent back and forth as if it were synchronous. > > > I have tried constraining with OFFSET IN and OFFSET OUT constraints > > that can handle these 4 relative phases (basically constrain as if it > > were a 384 MHz clock) but this appears to be too much for the FPGA to > > handle. > > > Here are the constraints I defined in this case: > > > NET "clk_384mhz_p" TNM_NET "clk_384mhz_p"; > > TIMESPEC "TS_clk384mhz_p" =3D PERIOD "TS_clk384mhz_p" 10.4 ns HIGH 50%; > > > NET "outputData<*>" OFFSET =3D 0.6 ns AFTER "clk_384mhz_p"; > > NET "inputData<*>" OFFSET =3D IN 1 ns VALID 1.6 ns BEFORE > > "clk_384mhz_p"; > > > Another idea I have tried is to use source synchronous design to > > forward the 96 MHz clock (as a differential clock) with the data and > > then use a FIFO to move it into the "receiving" 96 MHz clock domain > > after clocking it in with the "originating" =A096 MHz. =A0Once again > > though, the design has trouble meeting timing. > > > Here are the constraints I defined in this case: > > > NET "clk_384mhz_p" TNM_NET "clk_384mhz_p"; > > TIMESPEC "TS_clk384mhz_p" =3D PERIOD "TS_clk384mhz_p" 10.4 ns HIGH 50%; > > > NET "originatingClk_p" TNM_NET =3D"originatingClk_p"; > > TIMESPEC "TS_originatingClk_p" =3D PERIOD "originatingClk_p" 10.4 ns > > HIGH 50%; > > > NET "outputData<*>" OFFSET =3D 5 ns AFTER "clk_384mhz_p"; > > NET "inputData<*>" OFFSET =3D IN 4 ns VALID 4 ns BEFORE > > "originatingClk_p"; > > > Does anybody have any insight into the best way to solve this problem? > > > Thanks! > > I vote for your second approach. =A0Which timing constraint are > you having trouble with? =A0For source-synchronous data you don't > need to concern yourself with offset output constraints as long > as all of your data and clock signals are registered in the IOB's. > > Use DDR flip-flops for the clock and standard flops for data > unless you need DDR rates. =A0Center the active clock edge in the > data window. =A0Use the same IO standard for clock and data for > lowest skew. =A0At 96 MHz this should give the other end of the > link close to 5 ns setup and hold. > > Regards, > Gabor Thanks for the response. I was having trouble with both timing constraints but I didn't have the data registered in the IOBs and I wasn't using a DDR register to output the clock. I've updated my design so the output clock is going through an ODDR to center the edge in the data window. All of the output data signals and the output clock are now registered in the IOBs. All of the input data is now registered in the IOBs and the input clock goes into a BUFR. Both clock and data are now single ended and LVCMOS25. I've removed the OFFSET OUT timing constraint and updated the OFFSET IN timing constraint to NET "inputData<*>" OFFSET =3D IN 4 ns VALID 8 ns BEFORE "originatingClk_p"; I just finished building the first FPGA and it passed timing. Now onto the second one....we'll see how it goes!Article: 144112
-jg wrote: > > You can also generate reports that count pin pairs/nets etc.. That's an excellent idea. Matching net reports across revisions might save some time. Thank you. > You can also safely re-import a netlist at any time, > and it simply skips existing pin pairs, and will add any missing ones, > which will stand out as unrouted. > > Is it Viewdraw, or Pads that drops the info ? > Is this a whole net, or a pin-pair ? > Re-importing the netlist seems to be the issue. Entire nets disappear and the previously routed tracks are ripped up and discarded. I can't say for sure that there is no indication that anything is wrong, since another engineer is responsible for the PADS side, but if there is, it isn't obvious enough for her, nor her predecessors, to notice. CurtArticle: 144113
My mistake. It's nothing like make and is not more flexible than make, although it is simpler than make. I meant to say it is more flexible than a batch file implementation. --steve "Oscar Almer" <o.almer@gmail..com> wrote in message news:20091111111327.632100c8@hummingbird... I am somewhat surprised about the assertion that it's more flexible than make, as the entire point of make is to be as generic and flexible as possible. Thanks for pointing it out, as I was previously unaware of it, and it might come in handy one day. //OscarArticle: 144114
On Nov 11, 11:13=A0am, -jg <jim.granvi...@gmail.com> wrote: > .... > I've sent Dimiter a disk image of an .ABL project compiled into a > XCR3128, so he can check what has changed.... While having my morning coffee at 11 PM (still half full) I tried the newest version I have here (ISE11) on my test project, the one with the one toggling bit shifting through another five. I got a warning that the project would be converted to a new format not usable by older versions; and a promise the old version would be zipped somewhere (yet to check that, but I have the source on my DPS disk beyond any alien access anyway). The the project got open, but the Abel source was gone; the top source now was its translation to vhdl. Fair enough, I thought, I was warned for that sort of thing. What I was not warned of was the fact that it would no longer work... It just won't compile, I think it does not preserve the pin numbers I have assigned in the Abel file. I suppose it can be tweaked to eventually work, if there were any sane reason why someone would want to do that. I don't, that's sure :-). But I was reminded once more why it is so important to have all design tools under control, the coolrunner series is the finest programmable silicon I have seen and I clearly will have to adapt my lc to the 3 and perhaps 2 series, hopefully they will live for another while. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/Article: 144115
On Nov 12, 9:21=A0am, Curt Johnson <curt.john...@dicombox.net> wrote: > -jg wrote: > > > =A0You can also generate reports that count pin pairs/nets etc.. > > That's an excellent idea. Matching net reports across revisions might > save some time. Thank you. > > > =A0You can also safely re-import a netlist at any time, > > and it simply skips existing pin pairs, and will add any missing ones, > > which will stand out as unrouted. > > > Is it Viewdraw, or Pads that drops the info ? > > Is this a whole net, or a pin-pair ? > > Re-importing the netlist seems to be the issue. > Entire nets disappear and the previously routed tracks are ripped up and > discarded. I can't say for sure that there is no indication that > anything is wrong, since another engineer is responsible for the PADS > side, but if there is, it isn't obvious enough for her, nor her > predecessors, to notice. The humble netlist is a very good audit-check, and the supposedly smarter direct linkages may be quicker, but they can also sometimes be riskier.... So, if the changes are simple, I'd suggest using net-import-merge (that does NOT rip up any traces, but it does need some manual groundwork) If the changes are more complex, then use direct-linkages, but _follow_ that with a netlist import/compare check. ie The old "trust, but verify" :) -jgArticle: 144116
On Nov 12, 10:41=A0am, Didi <d...@tgi-sci.com> wrote: > On Nov 11, 11:13=A0am, -jg <jim.granvi...@gmail.com> wrote: > > > .... > > I've sent Dimiter a disk image of an .ABL project compiled into a > > XCR3128, so he can check what has changed.... > > While having my morning coffee at 11 PM (still half full) I tried > the newest version I have here (ISE11) on my test project, the one > with the one toggling bit shifting through another five. > I got a warning that the project would be converted to a new > format not usable by older versions; and a promise the old > version would be zipped somewhere (yet to check that, but I > have the source on my DPS disk beyond any alien access anyway). > The the project got open, but the Abel source was gone; the > top source now was its translation to vhdl. Fair enough, I thought, > I was warned for that sort of thing. Err No. I'd say NOT fair-enough. WHY should they need to replace YOUR source code ? If they have Abel-to-VHDL working, then simply run that in the background. I was told by a friend a couple of years back, that was how Xilinx handled his abel - it did VHDL spins, but they were 'hidden', and it took Xilinx a few months to knock the edges off that change, but it DID sound like it all worked. > What I was not warned of > was the fact that it would no longer work... It just won't > compile, I think it does not preserve the pin numbers I > have assigned in the Abel file. > I suppose it can be tweaked to eventually work, if there > were any sane reason why someone would want to do that. > I don't, that's sure :-). > But I was reminded once more why it is so important > to have all design tools under control, the coolrunner > series is the finest programmable silicon I have seen and > I clearly will have to adapt my lc to the 3 and perhaps > 2 series, hopefully they will live for another while. Have you looked at the Atmel ATF1508RE ? I use the CUPL tool flows on their ATF15xx family. It compiles in a fraction of a second, has a stable, flash-Drivable image and it can create test vector files. Hooked to a button in my favourite text editor. Simple.Stable.Bulletproof (well, almost: Zero Angst) -jgArticle: 144117
On Nov 11, 11:59=A0pm, -jg <jim.granvi...@gmail.com> wrote: > ... > I was told by a friend a couple of years back, that was how Xilinx > handled his abel - it did VHDL spins, but they were 'hidden', and it > took Xilinx a few months to knock the edges off that change, but it > DID sound like it all worked. That is true, it does seem to work. On the 6.3 version, at least. The end result I get does go through that conversion as well, I can see that during compilation, the vhdl source is also visible I think. What does seem not to work in the 11 thing is some higher level automation, they don't bother parsing the Abel source for pin assignments and endup without any (my assumption only, could be anything else). Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/ Original message: http://groups.google.com/group/comp.arch.embedded/msg/bc9= 607aec82349d8?dmode=3DsourceArticle: 144118
On Nov 11, 4:59=A0pm, -jg <jim.granvi...@gmail.com> wrote: > On Nov 12, 10:41=A0am, Didi <d...@tgi-sci.com> wrote:> On Nov 11, 11:13= =A0am, -jg <jim.granvi...@gmail.com> wrote: > > > > .... > > > I've sent Dimiter a disk image of an .ABL project compiled into a > > > XCR3128, so he can check what has changed.... > > > While having my morning coffee at 11 PM (still half full) I tried > > the newest version I have here (ISE11) on my test project, the one > > with the one toggling bit shifting through another five. > > I got a warning that the project would be converted to a new > > format not usable by older versions; and a promise the old > > version would be zipped somewhere (yet to check that, but I > > have the source on my DPS disk beyond any alien access anyway). > > The the project got open, but the Abel source was gone; the > > top source now was its translation to vhdl. > > =A0Fair enough, I thought, > > > I was warned for that sort of thing. > > Err No. I'd say NOT fair-enough. > WHY should they need to replace YOUR source code ? > > If they have Abel-to-VHDL working, then simply run that in the > background. > > I was told by a friend a couple of years back, that was how Xilinx > handled his abel - it did VHDL spins, but they were 'hidden', and it > took Xilinx a few months to knock the edges off that change, but it > DID sound like it all worked. > > > What I was not warned of > > was the fact that it would no longer work... It just won't > > compile, I think it does not preserve the pin numbers I > > have assigned in the Abel file. > > I suppose it can be tweaked to eventually work, if there > > were any sane reason why someone would want to do that. > > I don't, that's sure :-). > > But I was reminded once more why it is so important > > to have all design tools under control, the coolrunner > > series is the finest programmable silicon I have seen and > > I clearly will have to adapt my lc to the 3 and perhaps > > 2 series, hopefully they will live for another while. > > =A0Have you looked at the Atmel ATF1508RE ? > I use the CUPL tool flows on their ATF15xx family. > =A0It compiles in a fraction of a second, has a stable, flash-Drivable > image and it can create test vector files. > =A0Hooked to a button in my favourite text editor. > Simple.Stable.Bulletproof (well, almost: Zero Angst) > > -jg I would not consider ISE 11 for anything but the very latest FPGA's. ISE 6.3 is probably the most stable version and if your device is included, you should use it. I have to admit that I use Verilog almost exclusively for projects since moving away from Foundation 4.1 (the Aldec-based one) which had decent schematics. I still have that version running to support old projects, but I think it may predate the Coolrunner II. In any case that version certainly had Abel and I used it. It also had serious bugs including an inability to deal with paths that are not 8.3 all the way up from the root and a necessity to have the execution path point to the Abel compiler even when running from the GUI. The usual symptom if your file name was longer than 8 characters was to fail with no explanation given. Xilinx has already decided to orphan some older FPGA products with ISE 11. ISE 10.1.03i is the last version to support the older parts. It is also fairly stable and you can get the webpack version with a little bit of browsing (older versions are referred to as "classic"). In any case the GUI for newer tool versions seems to get less intuitive and more clunky with each version, as you have no doubt seen. I don't think Xilinx ever had a version that would allow top-level code in Abel, but I could be wrong on that because most of my designs are FPGA based rather than CPLD where top-level Abel would make sense. If you need to do anything serious with Coolrunner I'd suggest moving to VHDL or Verilog just to avoid the crappy schematic editor. Oh for the days of PALASM... Regards, GaborArticle: 144119
On 11 Nov., 19:29, Gabor <ga...@alacron.com> wrote: > On Nov 11, 12:45=A0pm, Guru <ales.gor...@gmail.com> wrote: > > > > > On Nov 11, 6:27=A0pm, Guru <ales.gor...@gmail.com> wrote: > > > > Hello everybody, > > > > I am developing a camera with a Spartan3A DSP and a sensor which uses > > > 1.8V LVDS. The Spartan 3A DSP datasheet says that only 2.5 and 3.3V > > > LVDS is supported. The signal rate is 108MHz DDR. > > > > Any suggestions what should I do? Specify in UCF LVDS_25 and pray to > > > work OK? > > > It is pretty much the same with a Spartan6. > > > > Best regards, > > > > Ales > > > I forgot to mention that transmitter (sensor) swing is typically 150mV > > (100-200mV) and need 100ohm termination. For termination I planned to > > use 110ohm IOB termination. > > > Best reagards, > > > Ales > > LVDS is LVDS regardless of the supply voltage. =A01.8V, 2.5V and > 3.3V LVDS all have the same common-mode voltage and differential > swing. =A0There should be mo problem interfacing these signals > to the Spartan 3A. =A0If the Spartan 3A doesn't have integrated > differential termination I would suggest using an external > resistor rather than burning up internal thevenin termination > current. > > Regards, > Gabor yep LVDS is LVDS, I guess the reason 1.8 isn't an option is that if the transmitter is at the upper limits of spec for offset and swing, a reciever running on 1.8V would get very close to the Vcc rail and the spec allows voltages up to 2.4V -LasseArticle: 144120
On Nov 12, 11:31=A0am, Gabor <ga...@alacron.com> wrote: > I don't think Xilinx ever > had a version that would allow top-level code in Abel, > but I could be wrong on that because most of my designs > are FPGA based rather than CPLD where top-level Abel > would make sense. =A0 The ABEL examples I have here, do not need to have SCH top levels. ( I think one does, to show how it can be done..) -jgArticle: 144121
On Nov 12, 11:20=A0am, Didi <d...@tgi-sci.com> wrote: > > That is true, it does seem to work. On the 6.3 version, at least. > The end result I get does go through that conversion as well, I > can see that during compilation, the vhdl source is also visible > I think. > > What does seem not to work in the 11 thing is some higher level > automation, they don't bother parsing the Abel source for pin > assignments and endup without any (my assumption only, could > be anything else). By default I think it auto-fits (floats the pins), but if you click Lock Pins, you get a .UCF for that fit pass, and can then move the pins about in that file. Usually I let the fitter have first pass, and create the reports etc, and then I start worrying about the pins. It's also good to get design thru the hoops once, before starting to nail things down.. Not extracting that info from ABEL is rather lazy of Xilinx - that's really intern level stuff, perhaps they don't sell that many PLDs into long design life projects ? Still, a generated UCF file looks simple enough.. -jgArticle: 144122
On Nov 11, 9:36=A0pm, Jan Pech <inva...@void.domain> wrote: > On Wed, 2009-11-11 at 06:14 -0800, Antti wrote: > > On Nov 11, 3:57 pm, Vijayan <vicchemi...@gmail.com> wrote: > > > Hi all, > > > > I am using virtex 5 (LXT) device in the design. In this, FPGA need to > > > interfaced with copper media 1000BaseT using the core "Ethernet > > > 1000BASE-X PCS/PMA or SGMII". > > > design flow would be "FPGA (MAC -> GMII to SGMII bridge -> GTP > > > transceivers) -> PHY with SGMII support -> 10/100/1000Base -T". > > > > Here my question is, In xilinx V5 datasheet DS100.pdf, it is mentione= d > > > "Tri-mode 10/100/1000 Mb/s Ethernet MACs > > > - LXT, SXT, TXT, and FXT Platforms > > > - RocketIO transceivers can be used as PHY or connect to > > > external PHY using many soft MII (Media Independent > > > Interface) options": > > > > Is it possible to directly connect FPGA to Coppermedia without using > > > the external PHY ? i.e, FPGA(SGMII) to copper media ? > > > > Or should the external PHY must always be available in copper media > > > design ? > > > > In Datasheet, what Xilinx is referring as " RocketIO transceivers can > > > be used as PHY" ? > > > > Note: I am not using 1000BaseX(fiber) in the design. > > > > Regards, > > > > Vijayan > > > for copper you need external PHY > > > Antti > > More precisely, for 1000BASE-T you need an external PHY. > > Jan Thanks for the solution !Article: 144123
I'm interested in a development board that supports dual gig ethernet PHYs and PCIE (or perhaps PCI-X). As part of that I'm also interested in 10/100/1000 daughter cards. I've seen the following boards (mostly from http://www.fpga-faq.com/FPGA_Boards.shtml): http://www.knjn.com/FPGA-PCI.html I've bought one of these to start with. It does only PCI and doesn't have a PHY (and therefore only does 10 meg, but thats a start :-)). One of the PHY daughter cards will let it do all three speeds. http://www.knjn.com/FPGA-PCIe.htm At this point this one is probably the board I'm looking at as it has PCIE and one of the daughter cards will give me dual gig PHYs (unless someone knows of a better one of course!). I've seen all the following boards, but am interested in any ones people know of that aren't on this list. Altera DK-DEV-1AGX60N http://www.digilentinc.com/Products/Detail.cfm?Prod=NETFPGA&Nav1=Products&Nav2=Programmable http://www.digilentinc.com/Products/Detail.cfm?Prod=S3EBOARD&Nav1=Products&Nav2=Programmable 10/100 phy ... http://www.plda.com/prodetail.php?pid=123 has a 3 spi daughter card, pcie ... http://www.sevensols.com/index.php?seccion=262&subseccion=268&lang=en Many of these don't have PHYs so I've been looking at daughter cards. I know of the following ones: 10/100 only but cheap! http://www.enterpoint.co.uk/moelbryn/modules/ethernet_phy.html dual 10/100/gig, probably what I want, but Marvell (which needs an NDA for the data sheet!). xilinx ug065 daughter card dual marvell alaska PHYs pn HW-AFX-BERG-EPHY Http://www.xilinx.com/products/devkits/HW-AFX-BERG-EPHY.htm http://www.morethanip.com MTIP-PHYWORKX-Kit 10/100/1000 national ns83865 PHY daughterboard I may end up with these as I can get a data sheet on the PHY without an NDA. MTIP-PHYWORKX-M-Kit 10/100/1000 marvel 88e1111 MTIP-PHYWORKX-2XDP83640 10/100 dual HSMC connector MTIP-PHYWORKX-NS848-Kit 10/100 national dp83848 http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,400,793&Prod=S3E1600 http://www.microtronix.com/products/?product_id=202 http://www.iaf-bs.de/products/add-on-boards/virtex4fx.de.html Again I would be interested in any other ethernet PHY daughterboards not listed here I'd be interested in hearing about them! Peter Van EppArticle: 144124
Peter We do have a couple of PCIe products in development that might be of interest depending on your timescales. Contact us off line if you want to know more on those. We are not likely to develop a a PCI-X board unless someone wants to pay the development and I guess a similar comment would come from our compeditors. Our 10/100 Phy Module is not Marvell based. I concur on problems on parts that have NDAs and we have not used Marvell for that very reason in any of our products. We can also offer "reasonable" priced custom modules to make I/O functions like this. It's not a big job to take the Phy design that say we use on Merrick1 and turn that into a module either for our DIL headers or our advanced Moel-Bryn socket. We already do Gigabit+ interfaces as Moel-Bryn modules for some customers. John Adair Enterpoint Ltd. On 12 Nov, 07:01, van...@sfu.ca (Peter Van Epp) wrote: > =C2=A0 =C2=A0 =C2=A0 =C2=A0 I'm interested in a development board that su= pports dual gig ethernet > PHYs and PCIE (or perhaps PCI-X). As part of that I'm also interested in > 10/100/1000 daughter cards. I've seen the following boards (mostly fromht= tp://www.fpga-faq.com/FPGA_Boards.shtml): > > http://www.knjn.com/FPGA-PCI.html=C2=A0 > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 I've bought one of these to start with. It do= es only PCI and doesn't > have a PHY (and therefore only does 10 meg, but thats a start :-)). One > of the PHY daughter cards will let it do all three speeds. > > http://www.knjn.com/FPGA-PCIe.htm > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 At this point this one is probably the board = I'm looking at as it has > PCIE and one of the daughter cards will give me dual gig PHYs (unless som= eone > knows of a better one of course!). I've seen all the following boards, bu= t > am interested in any ones people know of that aren't on this list. > > Altera DK-DEV-1AGX60N > > http://www.digilentinc.com/Products/Detail.cfm?Prod=3DNETFPGA&Nav1=3DProd= ... > > http://www.digilentinc.com/Products/Detail.cfm?Prod=3DS3EBOARD&Nav1=3DPro= ...=C2=A010/100 phy ...http://www.plda.com/prodetail.php?pid=3D123=C2=A0has= a 3 spi daughter card, pcie ... > > http://www.sevensols.com/index.php?seccion=3D262&subseccion=3D268=E2=8C= =A9=3Den > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Many of these don't have PHYs so I've been lo= oking at daughter cards. > I know of the following ones: > > 10/100 only but cheap! > > http://www.enterpoint.co.uk/moelbryn/modules/ethernet_phy.html > > dual 10/100/gig, probably what I want, but Marvell (which needs an NDA fo= r > the data sheet!). > > xilinx ug065 daughter card dual marvell alaska PHYs pn HW-AFX-BERG-EPHY > > Http://www.xilinx.com/products/devkits/HW-AFX-BERG-EPHY.htm > > http://www.morethanip.com > > MTIP-PHYWORKX-Kit =C2=A0 =C2=A0 =C2=A0 =C2=A0 10/100/1000 national ns8386= 5 PHY daughterboard > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 I may end up with these as I can get a data s= heet on the PHY without > an NDA. > > MTIP-PHYWORKX-M-Kit =C2=A0 =C2=A0 =C2=A0 10/100/1000 marvel 88e1111 > MTIP-PHYWORKX-2XDP83640 =C2=A0 10/100 dual HSMC connector > MTIP-PHYWORKX-NS848-Kit =C2=A0 10/100 national dp83848 > > http://www.digilentinc.com/Products/Detail.cfm?NavPath=3D2,400,793&Prod..= . > > http://www.microtronix.com/products/?product_id=3D202 > > http://www.iaf-bs.de/products/add-on-boards/virtex4fx.de.html > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Again I would be interested in any other ethe= rnet PHY daughterboards > not listed here I'd be interested in hearing about them! > > Peter Van Epp
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