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 I am looking for a PCI/PCI-X development Kit with ethernet (10/100/1000) as one of its connector. Device = Xilinx Virtex II with more than 2,000,000 gates. Avnet makes such boards but they have a lot of other stuff on them like usb, rs232, video in/out etc. too which I dont need. Does anybody know a vendor where I can find one? Thanks SubhekArticle: 68351
Thanks Rudolf and Antti "SneakerNet" <nospam@nospam.org> wrote in message news:ILMac.1374$d%6.39465@news.xtra.co.nz... > Hi Rudolf > > This is with regards to your usb 1.1 function core from opencores.org. > > Your USB clock needs a 48MHz clock speed. I have a Nios Development Board > with a 50MHz oscillator. I'm using a PLL to drop the speed to 48.076923MHz > (ratio of 25/26). Is that OK or does it have to be ditto 48MHz cuz that's > the best that I can get. > > Regards > >Article: 68352
Hi, According to the Xilinx reference guides a TPSYNC timing point can be attached to a net, macro pin, output or input pin of a primitive, or an instance. I want to attach it to the 'D' input of a FF in my design. Anyone know the UCF syntax for this? Background is that I'm trying to constrain a path between two FFs in different clock domains. One clock is from a DCM via a BUFG, the other clock is from an input pad, using the normal routing fabric. So, just using FFS to FFS in the two domains doesn't work because the timing tool insists on a 'Clock Path Skew'. How it thinks it knows the skew between two asynchronous clocks, I don't know! I can use MAXDELAY on the nets, but this won't include Tcko or Tdick. Also, I used TPSYNC on the 'from' instances to the FFS in the 'to' clock domain, but this left out Tcko. So close! Ta, Syms.Article: 68353
Hello, Does anybody know what logic can be successfully placed into Virtex II Block RAM? I have a design with a mux and output registers but nothing gets mapped into the BRAM. I get a message from XST saying macro inferrence needs to be turned off. Xilinx XST User Guide contains a section on placing logic into BRAM but nothing on what can and can not be placed. Thanks JoshArticle: 68354
Chris Balough wrote: > Hi Hendra, > > Hope you won't mind my providing some clarification regarding > availability of ModelSim from Altera. Your post suggested we don't > provide ModelSim, when in fact we do. > > At Altera, one way we provide our software development tools is > through the Altera Subscription program (more details at > http://www.altera.com/products/software/order/ord-subscription.html > and http://www.altera.com/products/software/pld/products/partners/eda-ms.html). > In addition to our Quartus II software development tool, this > subscription *does include* an Altera-only version of ModelSim. <snip> Hi Chris, An earlier poster in this thread made this claim ".. AHDL is being abandoned even by Altera's newer tools." Can you comment on that ? AHDL will/does support MAX II, for example ? I know designers who use AHDL, and find it very productive in the CPLD space, and there must be large numbers of legacy designs coded in AHDL out there. -jgArticle: 68355
See below for one potential issue: the synthesis translate_off and
translate_on directives should surround the simulation-only portion of the
code.
Jason
"Patrick Robin" <circaeng@hotmail.com> wrote in message
news:1c77d44b.0403272022.24c1a7e@posting.google.com...
> Hello,
>
> I have been trying to use distributed ram on a Spartan 3. I get an
> error from XST with with this simple example from the docs
>
> error:
>
> Analyzing Entity <RAM16x1S> (Architecture <low_level_definition>).
> ERROR:Xst:764 - E:/data/f100/f100mb/dutyRAM16.vhd line 48: No default
> binding for component: <RAM16X1S>. Generic <INIT> is not on the
> entity.
>
>
>
> -- This example shows how to create a
> -- RAM using xilinx RAM16x1S component.
> library IEEE;
> use IEEE.std_logic_1164.all;
>
-- synthesis translate_off
> library UNISIM;
> use UNISIM.VComponents.all;
-- synthesis translate_on
>
> entity myRAM is
> port (
> o : out std_logic;
> we : in std_logic;
> clk : in std_logic;
> d : in std_logic;
> a0,a1,a2,a3 : in std_logic
> );
> end myRAM;
> architecture xilinx of myRAM is
> component RAM16x1S is
> generic (INIT : string := "0000");
> port (
> O : out std_logic;
> D : in std_logic;
> A3, A2, A1, A0 : in std_logic;
> WE, WCLK : in std_logic
> );
> end component;
> begin
> U0 : RAM16x1S
> generic map (INIT => "FFFF")
> port map (O => o, WE => we, WCLK => clk, D => d,
> A0 => a0, A1 => a1, A2 => a2, A3 => a3);
>
> end xilinx;
>
> --------------------------------------------------------------------
>
>
> Am I missing something?
>
> Thanks
>
> Patrick
>
Article: 68356BrakePiston <brakepiston@REMOVEyahoo.co.uk> wrote in message news:<lnsl60dsrdvqv78qhoubp9r4s2unqifnm2@4ax.com>... > Hi guys, > > I am having a strange problem. > > I have my schematic file, made up of lots of nice LUTs, gates, etc. My > inputs are represented by an I/O marker followed by either an IBUF, > OBUF, or BUFG for input, output and clock signals. > snipping While a large block is incomplete, it often has far more IOs than can fit in a package you might be targeting. Instead I run a scan in chain on one side for all inputs and another on the other side to collect outputs. The top level block now only has ck, scanin, scan out, fits in every package but does use quite a few FFs which I subtract from the synth report. Since the 2 scan chains can be ucf'ed, they can also bring their signals close enough to where needed in a final floorplan so that they don't contribute any real delay to the proto design when you try to get PR timing. The only issue this brings up is lots of false warnings that FFx (in scan chain) is same as FFx+1 (in my pipeline) and so on, but these are safe to ignore since I already know that. Once the logic loop is closed, the scan chain falls away quickly leaving the final design. Before I did this, I often lost the whole design too, except a few inputs! Kinda of pulling up oneself by bootstraps. regards johnjakson_usa_comArticle: 68357
jose.desousa@inesc-id.pt (Jose T. de Sousa) wrote in message news:<4694c849.0404010707.10064885@posting.google.com>... > I work for a company who recently released a new Spartan 2E 300 board > and we would like to list it in the www.fpga-faq.com/FPGA_Boards.shtml > site. > > Does anybody know how to do this ? > > Thanks > > Jose At bottom of board list it says to contact philip dot freidin AT fpga dash faq dot comArticle: 68358
I am curious if anyone here has had success maintaining a very low BER link using the fiber connections on the ML300 boards. We have implemented an Aurora Protocol PLB Core for the ML300 (adding interface FIFO and FSMs to the Aurora CoreGen v2 core. It is currently a single lane system using Gige-0 on the ml300 board (MGT X3Y1). We were having small issues using the 156.25 bref clock so we are currently using a 100 MHz clock (we are just using the PLB clock plb_clk out of the Clock0 module on the EDK2 reference system). Clock compensation occurs at about 2500 reference clocks. (tried 5000, same, if not worse problems). Best results were with Diffswing=800mv, Pre-Em=33%. Unfortunately our link has problems staying up for more than 20 minutes (it will spontaneously lose link and channel, until a mgt-reset on both partners kicks them off again). Additionally, there are mass HARD and SOFT errors reported by the Aurora core. I do not send any data, just let the Aurora core auto-idle. This is the timing: DIFFSW=800 PREEM=33% Stays up: 30+ minutes, ~5 soft errors/sec DIFFSW=700 PREEM=33% Stays up: 30+ minutes, ~10 soft errors/sec DIFFSW=600 PREEM=33% Stays up: not tested, ~20 soft errors/sec (explodes to 200-300 errors/sec at about 13 minutes) DIFFSW=500 PREEM=33% Stays up: not tested, ~30 soft errors/sec (explodes to 200-300 errors/sec at about 13 minutes) DIFFSW=800 PREEM=25% Stays up: not testeds, ~200-300 soft errors/sec - In loopback mode (serial or parallel) the channel/lane are crisp and clean as ever. - When the boards start up, the errors in each situation are small parts/second, but then grow over time. I dont know if this is a function of board/chip temperature (i put a heat sink on and it seems to slow the increase of the error rate), or if for some reason the Aurora core cannot compensate for some clock skew and jitter - Could any of you guys steer me in the right direction? Is the higher loaded plb_clk as my ref_clk a source of problem? Anybody able to get low error rates? Thanks, TonyArticle: 68359
Hi Gabor, You may want to consider the Altera Cyclone EP1C4 device. This device uses a staggered pad ring to deliver more I/Os (and consequently fewer LEs) in a given die size than the other Cyclone members. The device is available in 324- and 400-pin FBGA packages giving you 249 and 301 user I/Os to work with respectively. I know nothing about pricing beyond what is on our main website ($7.50 based on 250K unit volumes in 2004 time frame) -- I'd suggest you contact an Altera distributer or sales rep to investigate cost. Go to http://www.altera.com/cyclone for more details on the Cyclone family. Regards, Paul Leventis Altera Corp.Article: 68360
Amaury Anciaux wrote: > The bus macro doesn't seem to lack anything, but I discovered that if > I route the concerned signal to a "pip" further to the left, the > design finally routes. So it seems that the PAR needs to have that > first part of the path to route the signal. The tools still seem to have enormous problems with bus macros and all related things... The thing that irritates me most is that in your case it was always the same bit that did not get routed, so that's why I assumed there was something wrong with the macro. > Another question, are the bus macro really compulsory? If I use a > custom bus macro, without TBUFs, just to be sure that the signal > passes through the same nets, will it work? Haven't tried... A colleage of mine once tried implementing a macro with LUTs, i.e. do the routing without longlines and TBUFs, and use the slice's Inputs/Outputs as the macro ports. That only works for CLBs directly adjacent. But he said par always crashed in that case. couldn't wuite cope with those manually routet nets... That was par from ISE5.2, though, maybe it works now in ISE6. Best regards, Sean DurkinArticle: 68361
"Kenneth Land" <kland1@neuralog1.com1> wrote in message news:106p5chij03th48@news.supernews.com... > Hello, > > I'm having a problem reading a single one byte register on a Nios/Cyclone > board. I've seen this on the devkit board as well. Every time I read a > single memory location, the Nios is automatically generating reads for the > next 3 locations as well. > > This causes bad things to happen when you are reading a location that is > within 3 bytes of a location that does not want to be read. > > There doesn't appear to be a setting in the SOPC User Logic GUI. Is there a > .ptf file entry I can edit to stop this behavior? > > The UL has 5 address bits, 8 databits, (RD#,WR#,CS#) and is an Avalon Memory > Slave. > That's the way the Nios works - it *always* reads 32-bit word, and then throws away the data it doesn't want. Theoretically, a bus master can use the byte enable signals to tell a slave device which bytes it is interested in, but in practice that doesn't happen. I would suggest that you either use the full 32-bit databus (just ignore unused bits, and they will be pretty much optomised out), or make sure that you don't have side effects on reads (it's not normally a good idea to have such side effects anyway, although it's traditional for things like uart receive registers), or space your critical registers within the address space so that each such critical register takes 4 bytes of address space.Article: 68362
On 1 Apr 2004 19:24:58 -0800, johnjakson@yahoo.com (john jakson) wrote: >jose.desousa@inesc-id.pt (Jose T. de Sousa) wrote in message news:<4694c849.0404010707.10064885@posting.google.com>... >> I work for a company who recently released a new Spartan 2E 300 board >> and we would like to list it in the www.fpga-faq.com/FPGA_Boards.shtml >> site. >> >> Does anybody know how to do this ? >> >> Thanks >> >> Jose > > >At bottom of board list it says to contact > > philip dot freidin AT fpga dash faq dot com In all fairness to Jose, I added this to the page after I answered his question. :-) For anyone else that sells a boards with FPGAs, you can email me to have them added. Please include URLs and prices, and if possible in the same format as the current page, to make it easier for me to update. Thanks. =================== Philip Freidin philip.freidin@fpga-faq.com Host for WWW.FPGA-FAQ.COMArticle: 68363
On 1 Apr 2004 06:19:47 -0800, gabor@alacron.com (Gabor Szakacs) wrote: >I'm looking into a crosspoint switching application where >it appears FPGA's are the best choice even though I won't >use much of the internals. What I'm looking for is the >best price per I/O pin of relatively fast parts. Newer >releases of FPGA seem to target better price per logic cell >rather than I/O so I've already noticed that from Xilinx >I can do better with Spartan 2e than Spartan 3 in terms of >cost per I/O pin. Obviously smaller parts in each family >also giver better price per I/O because there are more >I/O's per logic cell. Any suggestions for a better price >would be appreciated. > >Also the reason I'm not currently looking at CPLD's is that >the application requires soft upload and I don't want parts >with limited programming cycle life (EPROM or FLASH based). >256 I/O's per part is a good match for the design although >even at this level I will need multiple parts. Right now >I'm more interested in what family to use for the best price >per I/O and then I'll pick the device size that fits best. Given your application, you may want to review a paper presented at the 2003 FCCM conference: A High I/O Reconfigurable Crossbar Switch Steve Young, Peter Alfke, ColmFewer, Scott McMillan, Brandon Blodget, and Delon Levi The procedings are available through the IEEE, but maybe you can get a copy directly from the authors, who are all at Xilinx. Peter Alfke is a regular on this news group. Philip Freidin FliptronicsArticle: 68364
xapp134 seems to be stupid when it comes to remembering active rows in the banks being accessed. it forces each read/write operation to go through a "row activation" phase which might not be necessary. all that it needs to do is maintain 4 registers which hold the value of the currently active rows in each of the banks to determine whether or not to issue a new "row activation" command. the xess code does better by remembering the active row within a bank, but surprisingly forces a "row activation" on a bank change. this is clearly not required if the row in the new bank has previously been activated. i guess if you are worried abt ur memory bandwidth, u are better off handtweaking the code to enable this. nachiket. george_mercury@hotmail.com (George) wrote in message news:<6d167a0a.0403310856.296ccff8@posting.google.com>... > I am sorry I cannot help you with the Xapp134 SDRAM controller, but > you might consider checking the new version of the SDRAM controller > from XESS ( you can get it free from www.xess.com ). I haven't tried > it myself, but it seems like a really neet and fast controller. It is > also reasonably well documented, although not as good as the Xapp134 > may I add. > > Best of luck with your project, > George MercuryArticle: 68365
Hi everybody, I have some problem to understand the bitstream, in the application note XAPP138 (v2.7) it’s written page 21, table 9, it appears the Bitstream Data Frames and CRC command set. In this one, FDRI is written a first time to 3000 4000h, then the number of data words needs to be indicated, the data frames are sent (the number relies on the previous packet Header type 2), the FAR is entered, the next frame address, and the same thing twice more. My questions are: · The data words number does it have to take in account the pad words (See XAPP151 (v1.6) p24 “FDRI”)? · The data frames do they need to be divided in three to respect the 3 packets data or multiply by 3? · What is the expected value of the next two FDRI? Thanks for your contribution, Cyrille lambertArticle: 68366
"David Brown" <david@no.westcontrol.spam.com> wrote in message news:c4j5s7$rql$1@news.netpower.no... > > "Kenneth Land" <kland1@neuralog1.com1> wrote in message > news:106p5chij03th48@news.supernews.com... > > Hello, > > > > I'm having a problem reading a single one byte register on a Nios/Cyclone > > board. I've seen this on the devkit board as well. Every time I read a > > single memory location, the Nios is automatically generating reads for the > > next 3 locations as well. > > > > This causes bad things to happen when you are reading a location that is > > within 3 bytes of a location that does not want to be read. > > > > There doesn't appear to be a setting in the SOPC User Logic GUI. Is there > a > > .ptf file entry I can edit to stop this behavior? > > > > The UL has 5 address bits, 8 databits, (RD#,WR#,CS#) and is an Avalon > Memory > > Slave. > > > > That's the way the Nios works - it *always* reads 32-bit word, and then > throws away the data it doesn't want. Theoretically, a bus master can use > the byte enable signals to tell a slave device which bytes it is interested > in, but in practice that doesn't happen. > > I would suggest that you either use the full 32-bit databus (just ignore > unused bits, and they will be pretty much optomised out), or make sure that > you don't have side effects on reads (it's not normally a good idea to have > such side effects anyway, although it's traditional for things like uart > receive registers), or space your critical registers within the address > space so that each such critical register takes 4 bytes of address space. > > > Hi David, Yeah, it would be fine except my register device has a register that is a fifo. So if I read any register in the same quad alignment it inadvertantly pops a value out of the fifo. Here's something I don't know about it yet. Where does the other data bytes read go? Does it put all four read results into different bytes of a register? For example: byte_val = *byte_register_ptr; It actually reads not only the byte I'm interested in but all four bytes around the location pointed to by the ptr. What does the Nios do with the other three bytes that it read? Bit bucket? Thanks, KenArticle: 68367
Hi everybody, I have some problem to understand the bitstream, in the application note XAPP138 (v2.7) it's written page 21, table 9, it appears the Bitstream Data Frames and CRC command set. In this one, FDRI is written a first time to 3000 4000h, then the number of data words needs to be indicated, the data frames are sent (the number relies on the previous packet Header type 2), the FAR is entered, the next frame address, and the same thing twice more. My questions are: · The data words number does it have to take in account the pad words (See XAPP151 (v1.6) p24 "FDRI")? · The data frames do they need to be divided in three to respect the 3 packets data or multiply by 3? · What is the expected value of the next two FDRI? Thanks for your contribution, Cyrille lambertArticle: 68368
Thank you all for your replies. I have tried debugging mi design using simple AND and OR gates, and what I found is that all my LUTs are being optimized!! So I did a simple design, one 2 4-input LUTs, one and gate, 8 inputs and 1 output.The LUTs are initialized with different numbers. All gets optimized away. Obviously, it works if I only have other components, such as gates. Anyone has any idea what's going on? Thanks On Thu, 01 Apr 2004 10:53:05 -0700, Bret Wade <bret.wade@xilinx.com> wrote: >PO Laprise wrote: >> John Retta wrote: >> >>> This typically happens when output signals from a logic block are not >>> connected (though a typo or some other unintended reason) ... as >>> MAP works backwards it trims away. >>> >>> To find the offending path, either use a simulator (highly recommended), >>> or add some "debug only signals" .... which are the OR of all output >>> signals from a suspected block .... whose output is brought to a top >>> level I/O. If this small logic addition suddenly adds large amounts >>> of previously trimmed logic, then you know that the downstream signals >>> are being optimized away. >>> >>> Good luck. >>> >> >> It can also happen if a) the clock signal to your output flip-flops is >> unconnected somehow or (more common) b) the enable signal to these >> flip-flops is stuck low for some reason. >> > >This is true and the trim report in the .mrp file can sometimes be >misleading about where the trimming originated. I use the following >iterative process to debug unexpected trimming behavior: > >1. Pick an instance (usually a FF) from the logical design that is being >trimmed unexpectedly and apply an "S" property to all input/output nets. > >2. Rerun map and examine the resulting NCD in FPGA Editor. Note which >inputs/ouputs are undriven/unloaded or optimized to constants and what >affect this would have on the trimmed logic. This should identify the >direction that the trimming is coming from. For example, the CE input >may be GND. > >3. Once the direction of the trimming has been identified. apply more >"S" properties on the logic in that direction and repeat step 2. >Continue until the source of the trimming has been identified. > >Other tips: > >If you suspect that a FF is never going high, try applying an INIT=1 >property to it as a test. Does the trimming behavior change? > >If you reach a point where the "S" properties don't successfully block >some trimming, this is a sign that the logic is being removed due to >optimization. Usually one or more of the inputs has been optimized to a >constant. > >Bret Wade >Xilinx Product ApplicationsArticle: 68369
Hi, does anyone know if it's possible to display short signal names in the wave window of modelsim. I have for instance a signal /gb_eth_tb/ethernet_mac/receive_state in my wave window. How can I get modelsim so far that it only displays the name receive_state in the wave window. I saw that you can give it a "display name", can this be done by a script? TIA, FrankArticle: 68370
Hi, is it possible to compile only the files that needs to be compiled. I have a script which compiles a set of vhdl files, but if I do a change in the last vhdl file in the list, only this file needs to be recompiled. Is there an option for vcom that gives this desired behaviour? TIA, FrankArticle: 68371
Frank van Eijkelenburg wrote: > Is > there an option for vcom that gives this desired behaviour? Emacs vhdl-mode commands vhdl-generate-make-file and vhdl-make will do the job. Or the modelsim program vmake along with the OS program make will do what you want. -- Mike TreselerArticle: 68372
The Spartan 3 also uses a staggered IO ring. http://direct.xilinx.com/bvdocs/publications/ds099-1.pdf on page 4 of 5 lists all of the package IO combinations. For the 320 and 456 pin packages, we have 221, and 333 IOs. Prices ranges from $6.50 to $12 in large qty right now (2004). AustinArticle: 68373
"Kenneth Land" <kland1@neuralog1.com1> wrote in message news:106qpaadr24qoa4@news.supernews.com... > > "David Brown" <david@no.westcontrol.spam.com> wrote in message > news:c4j5s7$rql$1@news.netpower.no... > > > > "Kenneth Land" <kland1@neuralog1.com1> wrote in message > > news:106p5chij03th48@news.supernews.com... > > > Hello, > > > > > > I'm having a problem reading a single one byte register on a > Nios/Cyclone > > > board. I've seen this on the devkit board as well. Every time I read a > > > single memory location, the Nios is automatically generating reads for > the > > > next 3 locations as well. > > > > > > This causes bad things to happen when you are reading a location that is > > > within 3 bytes of a location that does not want to be read. > > > > > > There doesn't appear to be a setting in the SOPC User Logic GUI. Is > there > > a > > > .ptf file entry I can edit to stop this behavior? > > > > > > The UL has 5 address bits, 8 databits, (RD#,WR#,CS#) and is an Avalon > > Memory > > > Slave. > > > > > > > That's the way the Nios works - it *always* reads 32-bit word, and then > > throws away the data it doesn't want. Theoretically, a bus master can use > > the byte enable signals to tell a slave device which bytes it is > interested > > in, but in practice that doesn't happen. > > > > I would suggest that you either use the full 32-bit databus (just ignore > > unused bits, and they will be pretty much optomised out), or make sure > that > > you don't have side effects on reads (it's not normally a good idea to > have > > such side effects anyway, although it's traditional for things like uart > > receive registers), or space your critical registers within the address > > space so that each such critical register takes 4 bytes of address space. > > > > > > > Hi David, > > Yeah, it would be fine except my register device has a register that is a > fifo. So if I read any register in the same quad alignment it inadvertantly > pops a value out of the fifo. > > Here's something I don't know about it yet. Where does the other data bytes > read go? Does it put all four read results into different bytes of a > register? > For example: > > byte_val = *byte_register_ptr; > > It actually reads not only the byte I'm interested in but all four bytes > around the location pointed to by the ptr. What does the Nios do with the > other three bytes that it read? Bit bucket? > > Thanks, > Ken > You should have a look at the Nios programmers' reference manual (page 22 on my copy, but it might vary according to revision), which explains how the nios reads from memory and peripherals. It always reads an aligned 32-bit word, and then uses the EXT8D or EXT16D instruction to get the exact byte or half-word it wants (overwriting the data read with the extracted byte or half-word). Assuming you have control over the peripheral in question, it should not be too difficult to re-arrange the memory map to take this into account. mvh., DavidArticle: 68374
Tony, A well designed link should be error free (ie many many hours without a single bit in error). Contact the hotline for details about MGT support on specific ML300 series boards: some early versions were not designed for supporting links above 1 Gbs! as they were designed to show off the 405PPC(tm IBM) instead. So, there is a hundred things to check once you find out if your board was built for MGT usage, but you have to start somewhere: 1) is your refclk meeting the jitter spec? The MGTs require a very low jitter refclk. You can check this by observing a 1,0 pattern from the outputs of the MGTs and seeing how much jitter is there. Should be much less than 10% of a unit interval (bit period). If it is more than this, you have a tx jitter problem. If you loop with a bad jitter rx clock, everything is OK because the receiver is getting exactly the same bad clock to work with. 2) is your logic error free when looped back? I think you said yes, but often timing constraints may be missing, and the fabric is the source of errors. 3) are your errors in burts? or single? Bursts may indicate FIFO overflow/underflow (refclks far apart in frequency, and no means to deal with it, or the means is not working in logic -- when looped, the same clock is used, so no problem). 4) what is the channel? coax cables are not a differential channel, common mode noise will roar right into the receiver if the channel is not differential. Usually the coax's are used to connect the TX and RX pairs to a XAUI adapter module to the actual backplane (still not ideal, but at least most of the channel is differential). 5) what does the received eye pattern look like? This will tell you if you have a jitter problem, or an amplitude/loss problem. If the eye looks fantastic, that takes you right back to the digital processing, and takes away the analog side of things again.... 6) have you tried a far end loopback? Loop the digital data directly back to the far end tx from the far end rx to go back to the near end. 7) contact an FAE, and arrange to go to one of our 15 world wide RocketLabs(tm) locations where we have all of the equipment and resources to debug your board, and compare it with our own boards and designs in the labs. Austin Tony wrote: > I am curious if anyone here has had success maintaining a very low BER > link using the fiber connections on the ML300 boards. > > We have implemented an Aurora Protocol PLB Core for the ML300 (adding > interface FIFO and FSMs to the Aurora CoreGen v2 core. It is > currently a single lane system using Gige-0 on the ml300 board (MGT > X3Y1). We were having small issues using the 156.25 bref clock so we > are currently using a 100 MHz clock (we are just using the PLB clock > plb_clk out of the Clock0 module on the EDK2 reference system). Clock > compensation occurs at about 2500 reference clocks. (tried 5000, same, > if not worse problems). Best results were with Diffswing=800mv, > Pre-Em=33%. > > Unfortunately our link has problems staying up for more than 20 > minutes (it will spontaneously lose link and channel, until a > mgt-reset on both partners kicks them off again). Additionally, there > are mass HARD and SOFT errors reported by the Aurora core. I do not > send any data, just let the Aurora core auto-idle. This is the > timing: > > DIFFSW=800 PREEM=33% Stays up: 30+ minutes, ~5 soft errors/sec > DIFFSW=700 PREEM=33% Stays up: 30+ minutes, ~10 soft errors/sec > DIFFSW=600 PREEM=33% Stays up: not tested, ~20 soft errors/sec > (explodes to 200-300 errors/sec at about 13 minutes) > DIFFSW=500 PREEM=33% Stays up: not tested, ~30 soft errors/sec > (explodes to 200-300 errors/sec at about 13 minutes) > > DIFFSW=800 PREEM=25% Stays up: not testeds, ~200-300 soft errors/sec > > - In loopback mode (serial or parallel) the channel/lane are crisp and > clean as ever. > > - When the boards start up, the errors in each situation are small > parts/second, but then grow over time. I dont know if this is a > function of board/chip temperature (i put a heat sink on and it seems > to slow the increase of the error rate), or if for some reason the > Aurora core cannot compensate for some clock skew and jitter > > - > > > Could any of you guys steer me in the right direction? > > Is the higher loaded plb_clk as my ref_clk a source of problem? > Anybody able to get low error rates? > > Thanks, > Tony > > > > > >
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