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, After a very enjoyable few days trying to sort out a test design involving Ethernet and Virtex-4 I thought it time to ask some advice. I have a FX60's embedded MAC using RocketIO to talk 1000Base-X to an SFP module(cat5 copper) this is then cross-over cable connected to an Intel E1000 network card. There are no switches involved in the links. The design is based on the 1.4.1 reference design that comes with coregen 8.1 for the embedded-mac. I am not using the Host Interface or such like, just a basic logic hooked on the end of the MAC with it statically cconfigured using the tie-offs. I can get the PC with Intel card to send raw Ethernet frames to my virtex-4's mac address and they seem to get through about 40% of the time, and I see the "frame good" signal, the rest of the time I see a "bad frame". On looking at more signals I am seeing a large amount of disparity error and NotInTable coming from the RocketIO module and what looks like corruption or bit shifts on the data. I even see this when there is no traffic on the link and there are just idle frames being sent.. It seems semi-repetitive, with say the order of a few hundred good bytes between small bursts of bad ones. Anyone got any ideas? I have checked the network card, the cable(long ones, short ones, good quality ones and bad ones.) All cards and cables pass large statistic back-to-back testing at 1Gig between PC's with very few dropped frames. My initial thoughts were the reference clock being fed to the RocketIO (which i think is okay, its the ref clock from a PCIexpress socket going via a ICS9DB202 to clean it up and make it 125Mhz.) I have considered heat too, so we bolted a larger heatsink and fan onto the chip... Words of wisdom will be greatfully received... -- /\/\arc Kelly ..Just your average physicist trying to get by in a world full of normal people...Article: 104126
Marc Kelly wrote: > Hi, > > After a very enjoyable few days trying to sort out a test design > involving Ethernet and Virtex-4 I thought it time to ask some advice. > > I have a FX60's embedded MAC using RocketIO to talk 1000Base-X to an SFP > module(cat5 copper) this is then cross-over cable connected to an Intel > E1000 network card. There are no switches involved in the links. The > design is based on the 1.4.1 reference design that comes with coregen > 8.1 for the embedded-mac. I am not using the Host Interface or such > like, just a basic logic hooked on the end of the MAC with it statically > cconfigured using the tie-offs. Have you seen the release notes and applied all the fixes ? Also, I don't know about 1000BaseX, but with SGMII, you need a MDIO clock ... either internal (by configuring the divider with the host internal) or external (via the mdio clock in pin). Without it, I never could get the SGMII to autonegotiate witht the PHY ... > I can get the PC with Intel card to send raw Ethernet frames to my > virtex-4's mac address and they seem to get through about 40% of the > time, and I see the "frame good" signal, the rest of the time I see a > "bad frame". On looking at more signals I am seeing a large amount of > disparity error and NotInTable coming from the RocketIO module and what > looks like corruption or bit shifts on the data. > > I even see this when there is no traffic on the link and there are just > idle frames being sent.. It seems semi-repetitive, with say the order of > a few hundred good bytes between small bursts of bad ones. > > Anyone got any ideas? I'm working with EMAC and SGMII, and I had errors because my sgmii board already has AC coupling capacitors in the rx path (at the phy end), so with the on-chip ac coupling, the signal was just too attenuated. Switching off the internal ac coupling did the trick. > My initial thoughts were the reference clock being fed to the RocketIO > (which i think is okay, its the ref clock from a PCIexpress socket going > via a ICS9DB202 to clean it up and make it 125Mhz.) I have considered > heat too, so we bolted a larger heatsink and fan onto the chip... If it's from a PCIexpress socket, are you sure it's spread spectrum is deactivated ? If not, even with a pll, for a few ms, it will be quite off 125MHz ... SylvainArticle: 104127
Catherine, If I remember rightly last time I worked with Aurora (about a year ago) you needed a SWIFT license for ModelSim as Xilinx only provided a model of the MGT in this format. I might be out of date though .... Cheers, MikeJ www.fpgaarcade.com "Catherine Trammell" <catcall_13@hotmail.com> wrote in message news:ee9c7cd.-1@webx.sUN8CHnE... > Hi, I'm new to Aurora and am having trouble simulating the example design > the core generated. When I execute sample_test.do in ModelSim, nothing is > clocked, and many of the signals remain undefined. I think I'm missing a > library, because there are a few modules that are called but don't exist > in the project, specifically MGT0_GT11. I've downloaded all of the service > packs and updates, but only have evaluation versions of both ISE and > ModelSim; could that be the problem? Do I need to configure the MGT > beforehand and integrate it into the core? If so, how do I do that? > > Thanks, CatherineArticle: 104128
Marc, Have you designed the board with the Xilinx on in house ? After checking the quality of the reference clock I would look at the power supply to the MGTs and the quality of the PCB routing between the Xilinx and the SFP. Any way you can look at the RocketIO signals and check the eye pattern? /MikeJ (x-physicist) "Marc Kelly" <marc@achenar.eclipse.co.uk> wrote in message news:tfidnWvgXbi3lgrZRVny1Q@eclipse.net.uk... > Hi, > > After a very enjoyable few days trying to sort out a test design > involving Ethernet and Virtex-4 I thought it time to ask some advice. > > I have a FX60's embedded MAC using RocketIO to talk 1000Base-X to an SFP > module(cat5 copper) this is then cross-over cable connected to an Intel > E1000 network card. There are no switches involved in the links. The > design is based on the 1.4.1 reference design that comes with coregen > 8.1 for the embedded-mac. I am not using the Host Interface or such > like, just a basic logic hooked on the end of the MAC with it statically > cconfigured using the tie-offs. > > I can get the PC with Intel card to send raw Ethernet frames to my > virtex-4's mac address and they seem to get through about 40% of the > time, and I see the "frame good" signal, the rest of the time I see a > "bad frame". On looking at more signals I am seeing a large amount of > disparity error and NotInTable coming from the RocketIO module and what > looks like corruption or bit shifts on the data. > > I even see this when there is no traffic on the link and there are just > idle frames being sent.. It seems semi-repetitive, with say the order of > a few hundred good bytes between small bursts of bad ones. > > Anyone got any ideas? > > I have checked the network card, the cable(long ones, short ones, good > quality ones and bad ones.) All cards and cables pass large statistic > back-to-back testing at 1Gig between PC's with very few dropped frames. > > My initial thoughts were the reference clock being fed to the RocketIO > (which i think is okay, its the ref clock from a PCIexpress socket going > via a ICS9DB202 to clean it up and make it 125Mhz.) I have considered > heat too, so we bolted a larger heatsink and fan onto the chip... > > Words of wisdom will be greatfully received... > -- > /\/\arc Kelly > ..Just your average physicist trying to get by in a world full of normal > people... > >Article: 104129
Hello I am looking for good Tutorials which show how to implement a processor archtitecture for a FPGA. Also good tutorials how a copressor can be implemented would be interesting for me, preferably for Xilinx FPGAs. I know google will help me here a little bit, but perhaps one of you can suggest which were helpful to oneself. Thanks HansArticle: 104130
Mark McDougall wrote: > As others have concurred, definitely feasible. I have implemented a > read-only version of a WD1793 FDC in VHDL which interfaces to a SPI > serial flash device rather than a floppy drive. Cool! I could surely use that to add a "floppy" to my Sinclair Spectrum on an FPGA toy :) > > Some in this thread have talked about drive pules and MFM encoding etc > etc - that's *way* too low-level for your requirements. There is no need > to emulate operation at the physical encoding level - in fact you'd be > silly to do so! You need only emulate the register level interface of > the controller and implement a means to store the data for a disk image. I would not be so positive. Each approach has its merits. Consider the benefits of the MFM approach: 1. Any cheap micro is fast enough for 125K bits per sec. 2. No modification needed - connect to the floppy connector. -Alex.Article: 104131
MikeJ wrote: > Have you designed the board with the Xilinx on in house ? It's actually a prototyping board bought from PLDA (their XpressFX60 board) with the SFP sockets already on it. They're main selling point is its PCIexpress capability, but we're after it for the high speed IO currently. > Any way you can look at the RocketIO signals and check the eye > pattern? Its possible I think, would have to get our hardware people onto it, as I do mostly firmware and so they keep all very high spec scopes hidden from me :) -- /\/\arc Kelly ..Just your average physicist trying to get by in a world full of normal people...Article: 104132
Sylvain Munaut wrote: > Have you seen the release notes and applied all the fixes ? Yes, I had been hoping that one of them would magically fix things, sadly not. > Also, I don't know about 1000BaseX, but with SGMII, you need a MDIO > clock ... Without it, I never could get the SGMII to autonegotiate > witht the PHY ... I believe things are negotiating, although I may be wrong. The fact I am seeing real fames that work, and the system can echo them back to the PC as well gave me some confidence. I will check the MDIO clock issue however.. >> Anyone got any ideas? > I'm working with EMAC and SGMII, and I had errors because my sgmii board > already has AC coupling capacitors in the rx path (at the phy end), so > with the on-chip ac coupling, the signal was just too attenuated. > Switching off the internal ac coupling did the trick. Ah, that does sound interesting, I will have to check he schematics for the board(s) tomorrow at work and see.. It does seem to be the kind of thing that might be causing it.. if so, then I owe you many beers... > If it's from a PCIexpress socket, are you sure it's spread spectrum is > deactivated ? yeah, we turned off all the spread spectrum settings in a moment of inspiration.. sadly didn't seem to have any effects. I even tried clocking it from a DCM generated 125Mhz clock, just to see what happened.. same effect as the proper ref clock. -- /\/\arc Kelly ..Just your average physicist trying to get by in a world full of normal people...Article: 104133
> > It's actually a prototyping board bought from PLDA (their XpressFX60 > board) with the SFP sockets already on it. They're main selling point is > its PCIexpress capability, but we're after it for the high speed IO > currently. Ok, I know of that board - they should know what they are doing and I assume they have looked at the eye pattern. > >> Any way you can look at the RocketIO signals and check the eye >> pattern? > > Its possible I think, would have to get our hardware people onto it, as > I do mostly firmware and so they keep all very high spec scopes hidden > from me :) > I know that feeling - having had some colleagues break/misplace expensive probes :) Maybe it's worth replacing the reference clock with a quality low jitter differential oscillator and see if it makes any difference ? You can get away with some carefully matched length twisted pair mod wire - my company does it quite often ... but make sure the oscillator power supply is good - and put a smd cap across the pins of the oscillator at least. /MikeJArticle: 104134
> Maybe it's worth replacing the reference clock with a quality low jitter > differential oscillator and see if it makes any difference ? > You can get away with some carefully matched length twisted pair mod > wire - my company does it quite often ... but make sure the oscillator > power supply is good - and put a smd cap across the pins of the oscillator > at least. Just to clarify, that is a cap across the power pins of the oscillator! /MikeArticle: 104135
MikeJ wrote: >> Maybe it's worth replacing the reference clock with a quality low jitter >> differential oscillator and see if it makes any difference ? The board actually has a spare place for mounting an oscillator that feeds into one of the MGT reference clocks, I need to check to see if it feeds the correct column to be used to drive the RocketIO I need.. 'tis the joys of playing with such fun hardware I guess.. -- /\/\arc Kelly ..Just your average physicist trying to get by in a world full of normal people...Article: 104136
Well this is a long shot, but is it possible that one is fixed at Full Duplex (no-negotiate) while the other is trying to negotiate and falls-back to half-duplex? This is a fairly common problem that occurs and the link appears to work for simple 'pings', but any real traffic has massive amounts of errors. This is due to the fact that one is in full duplex and transmits while receiving and the half-duplex connection sees this as a collision. Just a possibility... and I'm only SURE that this happens with 10baseTX and 100baseTX, not with 1000baseX -bh "Marc Kelly" <marc@achenar.eclipse.co.uk> wrote in message news:x-idnS_g2JVsgwrZRVnytQ@eclipse.net.uk... > MikeJ wrote: > >> Maybe it's worth replacing the reference clock with a quality low jitter > >> differential oscillator and see if it makes any difference ? > > The board actually has a spare place for mounting an oscillator that > feeds into one of the MGT reference clocks, I need to check to see if it > feeds the correct column to be used to drive the RocketIO I need.. > > 'tis the joys of playing with such fun hardware I guess.. > -- > /\/\arc Kelly > ..Just your average physicist trying to get by in a world full of normal > people...Article: 104137
> transmitter CH7301C > for receiver look at www.ti.com > Hi, the CH7301C and all the DVI Tx/Rx chips from TI use high pin packages. There doesn't seem anything that has tube packaging that I can easily use on a breadboard (breadboard probably wouldn't work any way since there are such high speed signals). I know this is a cumbersome question, but is there any place where I can get a DVI Tx / Rx PCB board? I have seen one on the internet, but it is very expensive. I don't want to go through all the trouble of fab'ing a board if there is already one available. Thanks.Article: 104138
Alex Freed wrote: > Cool! I could surely use that to add a "floppy" to my Sinclair > Spectrum on an FPGA toy :) You're not the first to ask. I'll have to post the source it on my site. Be warned, it's really crappy code... ;) > I would not be so positive. Each approach has its merits. Consider > the benefits of the MFM approach: > 2. No > modification needed - connect to the floppy connector. You have a point, my mind was stuck in IDE land where the controller is basically integrated on the drive - I forgot early drives were so primitive! Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 104139
Agree with your reasoning, I rushed out a post and inevitably confused the situation :) Sorry. Peter Alfke wrote: > This is getting ever more confusing. > > I think we agreed already that there are roughly 2 million pixel x 60 > Hz, roughly 150 million pixel per second. > > There are three channels, one per color, and each pixel color is > represented by 8 serial bits. Encoded with 8B/10B this requires 10 > bits. 150 million pixel times 10 bits = 1.5 Gigabits per second. And > this obviously three times, once per color. > Inside the FPGA, the pixel color is represented as 8 bits in parallel, > which gets us back to a managable 150 MHz and a total of 24 chanels. > The serial bit rate is too high (by a factor 2) for general purpose > I/O, therefore, as I claimed, only dedicated inputs can handle such a > high bitrate of 1.5 Gbps. But if you are willing to dedicate a total of > 24 input pins (plus clocks), then the frequency is only 150 MHz, which > any modern chip handles easily. > > The total traffic is roughly 4 gigabits per second. There is no way > around that, unless you use compression. > > Can we all agree on this? > Peter Alfke, Xilinx Applications > ================Article: 104140
On Mon, 19 Jun 2006 23:13:13 +0200, "Hans Rhein" <ernte23@gmx.at> wrote: >Hello > >I am looking for good Tutorials which show how to implement a processor >archtitecture for a FPGA. Also good tutorials how a copressor can be >implemented would be interesting for me, preferably for Xilinx FPGAs. I know >google will help me here a little bit, but perhaps one of you can suggest >which were helpful to oneself. > There is a whole web site dedicated to this (and a Yahoo email list too) http://www.fpgacpu.org/ The best place to start is at http://www.fpgacpu.org/xsoc/cc.html and read the 3 PDFs at March, April, May from Circuit Cellar magazine. Have Fun! PhilipArticle: 104141
Hello, I am using ModelSim PE 6.1b for simulation. I have downloaded XAPP134(SDRAM Controller) form xilinx website. All modules are in VHDL. SDRAM Controller- VHDL Micron_VHDL Testbench_VHDL It seems the core is not behaving properly with the test bench. The core state machine always stays in idle state. Initial violations can be ignored but it stays in idle state even if we run for a longer duration. Kindly update if there are any changes in the core and also do suggest me how to simulate the Core using modelsim. We are facing problems both in functional as well as in timing.pls do the needful Thanks in advance… Rajendra CGArticle: 104142
In article <pan.2006.06.11.03.15.36.415791@example.net>, Rich Grise wrote: >OK, I decided to take a chance and download that 839MB shell script that's >written for RedHat Enterprise, and was doing OK, (I had to shell out as >root a couple of times to give the install script permission to write to a >new directory, but that felt kind of kewl. :-) ), and now I'm at kind of a >stopper. The graphic install has the progress bar at 99%, and there's a >/lib/modules/misc/windrvr6.o: kernel-module version mismatch > /lib/modules/misc/windrvr6.o was compiled for kernel version > 2.4.18-14 while this kernel is version 2.4.31. Not specifically for your distribution but here's something on recompiling xpc4drvr and windrvr6 for a different kernel: http://gentoo-wiki.com/HOWTO_Xilinx It looks to me as if unless you're using their programmer hardware you don't need to bother. Synthesis and schematic capture ought to work without this driver. Coincidentally, Xilinx mailed out my copy of ISE today, so I'll know soon enough ;-) -- AdamArticle: 104143
Hi Antti, where did you get it from? On http://www.impulsec.com/ I can only find 30 day evals and barely any bare Impulse-C product. Only the CoDeveloper Tools. best regards EilertArticle: 104144
backhus schrieb: > Hi Antti, > where did you get it from? > > On http://www.impulsec.com/ I can only find 30 day evals and barely any > bare Impulse-C product. Only the CoDeveloper Tools. > > best regards > Eilert http://www.impulsec.com/eval/limitedversion.html from the above page, get the limited version, no serial number or anything required. not time limited, but size limited. Note that the "limited" version is not the revision as latest eval version, those some examples, like the up-down counter do not work with the limited version (a bug that is fixed in the later releases). I hopr document and example design should get you started using the limited version, at least here I have a LED blinking :) AnttiArticle: 104145
The bit generated file name will be the top_module name.You can change the top module name or rename the bit file generated. johnp wrote: > I'm using Xilinx 8.1 and would like to find a way to have > bitgen create its output files with a different basename > from the default. > > It looks like ISE propagates the top level Verilog module > as the basename for all the subsequent files. Is there > any way to override this behaviour? I don't think the > 'other bitgen command line options" menu choice works > for this. > > Any ideas? > > Thanks! > > John ProvidenzaArticle: 104146
Which version of xilinx are you using?. Morten Leikvoll wrote: > Riddle:Where did that +64[ns] on source/dest clk come from?? > > > ========================================================================= > Timing constraint: TS_CORECLK = PERIOD TIMEGRP "NET_CORECLK" 7.800 nS HIGH > 3.900 nS > WARNING:Xst:2245 - Timing constraint is not met. > Clock period: 66.690ns (frequency: 14.995MHz) > Total number of paths / destination ports: 164005 / 21159 > Number of failed paths / ports: 75783 (46.21%) / 4474 (21.14%) > ------------------------------------------------------------------------- > Slack: -58.890ns > Source: sym/BLKRAM (RAM) > Destination: sym/tEMPTY (FF) > Data Path Delay: 5.928ns (Levels of Logic = 2) > Source Clock: DDR_CKFB1 rising 2.0X +64 at 0.693ns > Destination Clock: DDR_CKFB1 rising +64 at 1.387ns > > Data Path: sym/BLKRAM (RAM) to sym/tEMPTY (FF) > Gate Net > Cell:in->out fanout Delay Delay Logical Name (Net Name) > ---------------------------------------- ------------ > RAMB16_S18_S36:CLKB->DOPB3 2 2.394 0.903 sym/BLKRAM > (sym/parbit<3>) > LUT4_L:I3->LO 1 0.551 0.126 sym/earlyempty1 > (sym/earlyempty) > LUT4:I3->O 1 0.551 0.801 sym/_n02221 (sym/_n0222) > FDPE:CE 0.602 sym/tEMPTY > ---------------------------------------- > Total 5.928ns (4.098ns logic, 1.830ns route) > (69.1% logic, 30.9% route)Article: 104147
Hi, I have a memec V4-MB development kit.In it there is a programmable clock ics8442.I am trying to configure it,but not working.i tried in the testing mode to check the testclock is routing into the TEST port.But this is also not working. Is anyone worked with this programmable clock synthesizer.Please help me.i think i am driving all control signals correctly. regards subinArticle: 104148
The question is simple: Has anybody used small data areas from inside C/C++? I have been abel to use it frm within assembler (not much of adeed!), but I am unable to use it from insde C/C++ ciompiler, as it always complains of trying to use some variable via r13, while not being in theshort data area. I have even tried to use __attribute__ of gcc to force the section of a variable (that works!) but the compiler still complains. TIA, ZaraArticle: 104149
Does anyone know of any software, ideally freeware, which can use the above JTAG interfaces to exercise other JTAG interfaces on non FPGA devices? In my case I'd like to read the state of pins on an unrelated device.
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