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
Has anyone used any of the HW debug tools that are available for use with a logic analyzer? I'm talking about the FPGAView tool from First Silicon Solutions for the Tek analyzer, or the Dynamic probe from Agilent. I'm starting a new project, and have no analyzer. Some groups in the company are using Altera, some are using Xilinx. I'm reasonably neutral. Do you have any horror stories or successes? Any thoughts? RBArticle: 105401
I started from the beginning and followed all the steps you suggested. The result was the same - the red led was on and the green 'done' was off. Then I downloaded the mkdosfs and formatted the CF card as per answer record you recommended. Same result - 'Err' was on again. I have noticed that CF has decreased from 32MB to 24MB after formatting. I tested if the old demo ACE files worked - copied them back from the HDD to the card, they worked fine again, just not the new one created with iMPACT. What is the ACE file size that you created? All the demos are 1686KB and the new ACE created with iMPACT is 1674KB. I tried with just single ACE file on the CF, any of the demo files worked that way too, but not the new one. Also didn't work with the file structure generated by iMPACT: E:\my_ml402\rev0\rev0.ace E:\xilinx.sys I always had CFG ADDR switches set to 000111, and SW12 to SYS ACE position. Thanks for help. Dan Ed McGettigan wrote: > EEngineer wrote: > > I have changed the order: > > > > Device #0 was xcf32p > > Device #1 xc4vsx35 > > Device #2 xc95144lx > > > > Assigned the configuration bit file again to the xc4vsx35 device, > > generated ACE, put it on CF, again could not configure the board. > > > > I just went ahead and generated a new ML402 ACE file using 8.1i and > copy the files to the CF card with no issue or doing anything outside > of the flow (such as SVF edits that you have been mentioning). > > Try the following. > > 1) Start over with a new iMPACT System ACE project > 2) Call the "Collection" name "my_ml402" > 3) Only create one revision (rev0) > 4) Set up the device chain as above XCF32P -> XC4VSX35 -> XC95144XL > 5) Assign your 4VSX35 BIT file to the XC4VSX35 device > 6) Generate the System ACE file with no other edits > 7) Remove all of the files from your CF card > 8) Copy just the single ACE that you just generated to the CF card > 9) Insert the CF card in the ML402 > 10) Verify that SW12 is set to the SYSACE position > > If this works then you have a good ACE file. If it doesn't work go > back and double check that you really have the correct chain defined > and that your bitstream is targeting a SX35 device and that you generate > the BIT file with the startupclk = jtagclk setting. > > If you can't get a CF card with just an ACE file to work then you > probably have a mal-formated CF Card see this answer record to reformat > the card: http://www.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=14456 > > Now that the ACE file is known to be good. You either have an address > switch setting issue or you copied the files incorrect to the CF card. > > 1) Remove all of the files from the CF card again > 2) Copy the xilinx.sys and the "my_ml402" collection directory that you > generated earlier to the blank CF card. > 3) Verify that the CFG ADDR switches 1, 2 & 3 are in the OFF state for > an address of 000 > 4) Insert the CF Card in the ML402 > 5) The ACE file should now load > > > Ed McGettigan > -- > Xilinx Inc.Article: 105402
Andy wrote: > Too bad the author is a proponent of the ancient style of separate > clocked and combinatorial processes in VHDL. He even uses a third > process for registered outputs. > > I think he needs to discover what variables can do for you in a clocked > process. Really? Which of his arguments do you disagree with? I always thought of the two-process style as being redundant, but after reading Dr. Chu's argument, I'm revising my thinking. For one thing, this style makes it much less disruptive to change a Moore output to a Mealy and vise versa. My thanks to S.C. for the reference. Good one. TommyArticle: 105403
All of our development boards support LVDS with matched pair routing. Even our low cost Raggedstone has about 50+ pairs of signals usually matched in length 1mm or less that run together from the relevant pair on the FPGA to the DIL headers. They don't share with other things generally either. This is part of the reason we use large I/O count devices even on our cheap boards. It is a major differentiation between our product and something like the Spartan-3 and 3E starter kits that use relatively small I/O count devices. We also tend use the large size package because of the SSO advantage and in fact we have an internal production test for some the boards with a very large percentage of I/O, at large toggle rate, running over our boards at 50Mhz and we get very good performance. Conversely we have seen other peoples designs that use PQFP and TQFP packages having very serious issues with small percentage toggle rates at relative low frequencies and the advantage of a BGA package is very large and well worth the little bit of extra money to have in most design cases. Tarfessock1 will have support for LVDS built in a good percentage of the I/O if not all, I expect we will have 20+ pairs maybe even the lot to give 35 pairs. The grounding we will have to see how good it is and whether virtual grounds from FPGA I/Os are needed. However we do want to maintain the planned 70 I/O as it is fairly key to what we want to do outside the card itself. Ultimately whatever we do we won't please everyone and that is what market choice for. I do think we have formula that will win a lot of friends especially when the planned extended functionality becomes clearer in the shape of future add-on modules. I don't think the price is bad either especially if you qualify for student pricing but I'm sure someone will still point out the card costs more than it's constituent parts and designing it is cheap and not be equated in the price. John Adair Enterpoint Ltd. John_H wrote: > Not enough grounds is a serious problem for good, high speed design. If > there's a decent job done with differential routing for LVDS pairs (and LVDS > voltage banks) then the demands on the grounds are lighter, allowing both a > slow-speed, many I/O solution *and* a high-speed solution. The Spartan3E > Starter kit had more than a dozen differential pairs but only about 4 pairs > were "usable" because the others shared signals with LEDs or test headers > that left huge stubs. If you did a good job with differential pairs, the > speed might be pushed through the development connector. > > "John Adair" <g1@enterpoint.co.uk> wrote in message > news:1153470659.303728.303030@75g2000cwc.googlegroups.com... > > Bob > > > > Probably won't be as many as desireable but the option of using virual > > grounds using switched FPGA I/Os will be possible. I will also see if > > we can make any build options to hard ground what are I/O pins via > > solder bridge or 0201 resistor etc. > > > > Generally we could use a few I/O than we have available on the 120 way > > connector currently pencilled in but the next size up standard > > connector is 180 way and is a bit big physically for the card edge. > > Generally we are trying to an internal standard for what might be > > developed as future products beyond Tarfessock1. > > > > If we get a good response to this card it likely we will do a big > > brother version in Virtex-5 but that is only one of many projects > > competing for team time in Q4 and not guaranteed to happen as yet. > > > > John Adair > > Enterpoint Ltd. > > > > Bob Perlman wrote: > >> Hi - > >> > >> I don't know if anyone else has mentioned it, but please make sure you > >> have lots of grounds, well spread out, on the external module > >> connector(s). > >> > >> Bob Perlman > >> Cambrian Design Works > >> http://www.cambriandesign.com > >> > >> > >> On Thu, 20 Jul 2006 10:48:42 +0100, "John Adair" > >> <removethisthenleavejea@replacewithcompanyname.co.uk> wrote: > >> > >> >We have mentioned Tarfessock1 before and now at the last point where we > >> >can > >> >add features for the board. You know have the last chance to ask for > >> >things > >> >you might want in this Cardbus format card so do ask. Currently the spec > >> >on > >> >the card is as follows: > >> > > >> >Dual Spartan-3E (Device 1 notionallly fixed covering Cardbus interface > >> >etc), > >> >Device2 programmable from Device1 or SPI prom. > >> >Device 2 = XC3S1200 or XC3S1600 > >> >4 ch DAC > >> >8 ch A/D > >> >O/P JTAG - looks like parallel port + cable3 for programming outside > >> >target > >> >boards. Supported by Device1. > >> >1 serial RS232 interface outside world for MicroBlaze support etc. 1 > >> >internal serial (TTL) also possible to Device2. > >> >4 ch RS485 serial controllable half duplex. > >> >SDRAM + second SPI Flash on Device2 > >> >Approx 70 5V tolerant I/O to outside world. > >> >Switched 3.3V O/P to supported external modules that don't need to be > >> >powered all the time (i.e. for running in the wild on laptop battery > >> >etc). > >> > > >> >We are using a 120 pin connector to support all these features and there > >> >will be breakout board/s available to better pitches. > >> > > >> >We are currently still on schedule for a September launch. > >> > > >> >John Adair > >> >Enterpoint Ltd. - Soon to be Home of Tarfessock1. The Spartan-3E Cardbus > >> >Development Board. > >> >http://www.enterpoint.co.uk > >> > > >Article: 105404
Jonathan Bromley wrote:
>
> Our VHDL and Verilog courses teach language essentials
> and coding style, and discuss some generally-applicable
> design techniques such as FSMs, but to keep them generic
> (and a reasonable length!) we don't discuss how to design
> any specific kind of hardware. But we have often been
> asked to create a course covering "the art of good RTL
> design" or somesuch. What these customers seem
> to want is something like "thirty years of design
> experience in a three-day class".
I hear it stated like this:
"I'd like to try that technique, but
I'm not sure it will work so I'm sticking
with the way I did it last time."
And that's what many opencores designs
look like.
> It's never been
> feasible for us to do that, because the exact content
> would be so specific to the particular needs of any
> one customer. But an open, peer-moderated,
> frequently-updated repository sounds like a good
> idea to me. I don't mean a library of complete
> ready-cooked designs like opencores.org; rather,
> I'm thinking of a collection of "design patterns"
> and shared experience.
I imagine a site like opencores
with working synthesis and verification code
under version control. The difference would be
that all of the designs would be peer-reviewed
and make full use of advanced synthesis techniques.
The examples would be easy to read, understand and modify.
They would be simple, but non-trivial.
Working code would provide some confidence for the skeptical.
The same code base would provide the "design patterns"
for tutorial authors to reference and write about.
Designs might be combined structurally or procedurally.
They might be used as benchmarks for synthesis
or for evaluating the latest assertion based testing.
> Any takers?
I would be happy to write and review some code examples,
but we would need to find an interested retired person
to be the web master and chief editor.
-- Mike Treseler
Article: 105405Robin Coming from a similar direction is one of our TechiTips here http://www.enterpoint.co.uk/techitips/Previous_TechiTips/techitips_increment_synth.html. It is a little bit old now but the module build up approach described is still applicable to mixed language application. John Adair Enterpoint Ltd. Robin Bruce wrote: > Hi group, here's a question: > > Can I synthesise a component described in Verilog, obtain an EDIF, then > write a VHDL wrapper around it so as to integrate it into a greater > VHDL project. > > yours in ignorance, > > RobinArticle: 105406
One thing worth considering is using logic analyser cores from Xilinx - Chipscope or Altera - Signaltap themselves alone. If you are on a tightish budget they are very cost effective and very good. We find we don't usually need anything more and they are very portable, i.e. laptop, if you need to work in the field. Downside of thsee tools is they need resource in the FPGA. Using one of the hookups to an external analyser does mean less resource used in the FPGA and that is generally the only time I would use such an analyser. Even then I would take the option, if available, of starting with an oversized FPGA to allow the build in of an analyser function rather than plan to use an external analyser. John Adair Enterpoint Ltd. Rube Bumpkin wrote: > Has anyone used any of the HW debug tools that are available for use > with a logic analyzer? I'm talking about the FPGAView tool from First > Silicon Solutions for the Tek analyzer, or the Dynamic probe from Agilent. > > I'm starting a new project, and have no analyzer. Some groups in the > company are using Altera, some are using Xilinx. I'm reasonably neutral. > > Do you have any horror stories or successes? Any thoughts? > > RBArticle: 105407
"John Adair" <g1@enterpoint.co.uk> wrote: >Web page with block diagram and outline spec is now on website here >http://www.enterpoint.co.uk/moelbryn/tarfessock1.html. How about a programmable clock source? Even better, one which has equal / matched lines to each FPGA so both FPGAs get the same clock. Multiple independant frequencies would be better. This may also be a good selling point for universities, crossing a clock boundary is not trivial in most cases. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 105408
I've had passing interest in your offerings before - they look reasonable for the price and functionality offered. Your discussion about acute attention to differential I/O and use of BGA packages is making me think more seriously about shipping stuff across the pond. For Tarfessock1, I'm left wondering what needs to be developed by me versus what you would supply for CardBus access. I'm the FPGA guy, not into Windows drivers to save my life. I'll take another, closer look at your site this weekend, particularly the info you've generated so far for Tarfessock1. - John_H "John Adair" <g1@enterpoint.co.uk> wrote in message news:1153510536.728994.136460@75g2000cwc.googlegroups.com... > All of our development boards support LVDS with matched pair routing. > Even our low cost Raggedstone has about 50+ pairs of signals usually > matched in length 1mm or less that run together from the relevant pair > on the FPGA to the DIL headers. They don't share with other things > generally either. This is part of the reason we use large I/O count > devices even on our cheap boards. It is a major differentiation between > our product and something like the Spartan-3 and 3E starter kits that > use relatively small I/O count devices. We also tend use the large size > package because of the SSO advantage and in fact we have an internal > production test for some the boards with a very large percentage of > I/O, at large toggle rate, running over our boards at 50Mhz and we get > very good performance. Conversely we have seen other peoples designs > that use PQFP and TQFP packages having very serious issues with small > percentage toggle rates at relative low frequencies and the advantage > of a BGA package is very large and well worth the little bit of extra > money to have in most design cases. > > Tarfessock1 will have support for LVDS built in a good percentage of > the I/O if not all, I expect we will have 20+ pairs maybe even the lot > to give 35 pairs. The grounding we will have to see how good it is and > whether virtual grounds from FPGA I/Os are needed. However we do want > to maintain the planned 70 I/O as it is fairly key to what we want to > do outside the card itself. Ultimately whatever we do we won't please > everyone and that is what market choice for. I do think we have formula > that will win a lot of friends especially when the planned extended > functionality becomes clearer in the shape of future add-on modules. I > don't think the price is bad either especially if you qualify for > student pricing but I'm sure someone will still point out the card > costs more than it's constituent parts and designing it is cheap and > not be equated in the price. > > John Adair > Enterpoint Ltd.Article: 105409
I found the IDT5V9885 to be surprisingly cost effective. Intended to be a clock generator rather than a zero delay buffer style of clock regenerator, the filtering selections for on-chip filters appear to make the device robust enough for serious clock cleanup. Even spread spectrum is available within the one integrated device. I don't know if I'll get it on the prototypes due back within the month (I'm only a contributor, not the designer) but I sure would love to work with that part! External part count is low, programmability is high. "Nico Coesel" <nico@puntnl.niks> wrote in message news:44c140f7.1387066536@news.kpnplanet.nl... > "John Adair" <g1@enterpoint.co.uk> wrote: > >>Web page with block diagram and outline spec is now on website here >>http://www.enterpoint.co.uk/moelbryn/tarfessock1.html. > > How about a programmable clock source? Even better, one which has > equal / matched lines to each FPGA so both FPGAs get the same clock. > Multiple independant frequencies would be better. This may also be a > good selling point for universities, crossing a clock boundary is not > trivial in most cases. > > -- > Reply to nico@nctdevpuntnl (punt=.) > Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 105410
Hi! I have a lot of PCB's with the XCR5064C CPLD on them, and would like to put them to use. I am forced to use old software, since the new WebPACK doesn't have support for the old devices. I have used several hours browsing the help file to find out how i connect anything on a BUS (e.g. CB16CE output pins (15:0) I am going absolutely crazy, i can't find out how i do it! Can anyone tell me how i do this, step for step, as i am a new user of CPLD's. - preferrably link to a online article describing how it's done. As a start i would like to try this program: http://coen.boisestate.edu/smloo/rapidprototyping2005/manual/UM-SCH-Spartan3.pdf - yes i know i don't have a Spartan3, and the software version is not the same, but the idea behind is what counts. I like to start with the small things. Regards, Per Jensen, Denmark.Article: 105411
Hi All, I have put a first, quick&dirty version of my "fpgadbg" tool on the website: http://www.ise.pw.edu.pl/~wzab/fpgadbg This tool allows to record the signals inside of FPGA, and then read the recorded data e.g. via the VME or other interface. The recorded data may be then converted into the LXT file, which may be browsed and analysed with the gtkwave viewer. -- Regards, Wojtek Zabolotny wzab@ise.pw.edu.plArticle: 105412
It is a bit ironic but we actually probably ship more development boards to the US than within the UK. There is also a strange US tax situation such that our products are taxed lower than a US local company. A import tax called MFP does apply but is very small but I don't think Federal or State taxes get levied. If I'm wrong on that do tell me. We have spend many many hours talking and emailing various US bodies to try and get a definative answer without success. Here in the UK our equivalent-ish VAT gets applyed to everything including our daily Digikey orders. It is also worth saying that if you take the FEDEX option for carriage that in most cases you will get an order within 2 days. Occasionally customs will upset that schedule but this is a fairly low percentage and beyond our control to do anything about. The low cost carriage option we believe takes usually less than a week to get there if you go for that option. When we release the product I don't expect everything will be as polished as desireable but we will try and get a level that is generally OK. The basic level that I will expect to launch with will be Device1(XC3S250E) looking a Parallel Port/Parallel Cable III supporting the bigger Device2(XC3S1200E). If we get the build right it should just be a Parallel Port to the OS and will pick up a driver automatically. Beyond that basic level we will be producing a software GUI etc. to access A/D, DAC etc but that needs some time to sort put and unlikely to available at launch. John Adair Enterpoint Ltd. John_H wrote: > I've had passing interest in your offerings before - they look reasonable > for the price and functionality offered. Your discussion about acute > attention to differential I/O and use of BGA packages is making me think > more seriously about shipping stuff across the pond. For Tarfessock1, I'm > left wondering what needs to be developed by me versus what you would supply > for CardBus access. I'm the FPGA guy, not into Windows drivers to save my > life. > > I'll take another, closer look at your site this weekend, particularly the > info you've generated so far for Tarfessock1. > > - John_H > > > "John Adair" <g1@enterpoint.co.uk> wrote in message > news:1153510536.728994.136460@75g2000cwc.googlegroups.com... > > All of our development boards support LVDS with matched pair routing. > > Even our low cost Raggedstone has about 50+ pairs of signals usually > > matched in length 1mm or less that run together from the relevant pair > > on the FPGA to the DIL headers. They don't share with other things > > generally either. This is part of the reason we use large I/O count > > devices even on our cheap boards. It is a major differentiation between > > our product and something like the Spartan-3 and 3E starter kits that > > use relatively small I/O count devices. We also tend use the large size > > package because of the SSO advantage and in fact we have an internal > > production test for some the boards with a very large percentage of > > I/O, at large toggle rate, running over our boards at 50Mhz and we get > > very good performance. Conversely we have seen other peoples designs > > that use PQFP and TQFP packages having very serious issues with small > > percentage toggle rates at relative low frequencies and the advantage > > of a BGA package is very large and well worth the little bit of extra > > money to have in most design cases. > > > > Tarfessock1 will have support for LVDS built in a good percentage of > > the I/O if not all, I expect we will have 20+ pairs maybe even the lot > > to give 35 pairs. The grounding we will have to see how good it is and > > whether virtual grounds from FPGA I/Os are needed. However we do want > > to maintain the planned 70 I/O as it is fairly key to what we want to > > do outside the card itself. Ultimately whatever we do we won't please > > everyone and that is what market choice for. I do think we have formula > > that will win a lot of friends especially when the planned extended > > functionality becomes clearer in the shape of future add-on modules. I > > don't think the price is bad either especially if you qualify for > > student pricing but I'm sure someone will still point out the card > > costs more than it's constituent parts and designing it is cheap and > > not be equated in the price. > > > > John Adair > > Enterpoint Ltd.Article: 105413
I will see what we can do. The physical size of a Cardbus card does not allow much room for an optimal placement to trace length match. We may also have problems finding enough board area too and I don't think double siding components is a serious option given the tight height restrictions. At the 33Mhz the Cardbus notionally works at you would not have any issues using a common source clock of this frequency on any interface between the devices. Device1 is strictly limited in size and generally the intention is that most customers will not touch the shipping build programmed in. The through-put from Device2, via Device1 + Cardbus, to outside world will be limited by the Cardbus itself negating the need for a super fast interface between the devices. That all said we trying to support LVDS on the interface between the devices and a source synchronous approach will definately yield high bandwidth. I will be able to tell you more in a couple of weeks when the design will be pretty much fixed in schematic and layout placement. John Adair Enterpoint Ltd. Nico Coesel wrote: > "John Adair" <g1@enterpoint.co.uk> wrote: > > >Web page with block diagram and outline spec is now on website here > >http://www.enterpoint.co.uk/moelbryn/tarfessock1.html. > > How about a programmable clock source? Even better, one which has > equal / matched lines to each FPGA so both FPGAs get the same clock. > Multiple independant frequencies would be better. This may also be a > good selling point for universities, crossing a clock boundary is not > trivial in most cases. > > -- > Reply to nico@nctdevpuntnl (punt=.) > Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 105414
Hi Joseph, thanks a lot I will check all the thing you suggested and yes its a board made by us. Still I have some questions: The Calibration process with the dummy reads can be definitely observed using chip scope and it seems to be ok as the tap_select signal is asserted. Does that mean that at least the control and the DQS signals should be fine. The question I have is the following in the init sequence the controller just writes data to the RAM, the Ram itself does practically nothing. SO assuming the RAM wouldnt consist at all would the init and calibration sequence still be succesfull? I tried a board without RAM assembly and it didnt do anything so I assume not.. As I said before the data compare module fails so it could be a signal inttegrity problem which casuses the read out data to be corrupt. heiner Joseph Samson schrieb: > heinerlitz@gmx.de wrote: > > Hi ive got some news, > > > > the init and calibration process seems to be succesful as tap_sel_done, > > data_tap_select and init_memory signals toggle at the end of the > > calibration process. > > > > However the init_done signal which is driven by COMP_DONE is not > > asserted. As COMP_DONE is generated by the pattern compare module, it > > seems to me that the read out data is corrupted. > > > > Could this be right? > > Am I right with my conclusions? > > What to do now? > > I'm assuming that this is a board of your own design, and not a > prototyping board you bought off the shelf, because my first guess would > be that there is either a mis-wiring problem (my board had the > differential clock signals miswired + to -, even though we checked the > schematic about a hundred times) or a signal integrity problem (like > those missing terminators). You can try turning on ODT. You can either > change the parameters_0.v file, or regenerate the design from CoreGen, > clicking on the 'Set Mode Register" button and setting RTT to 75 ohms. > > There are two lines of attack: > 1. Is the command and address correct? > 2. Is the data correct? > > There are indirect ways to see if the commands are correct. Earlier, I > said that part of the calibration is to issue read commands and > calibrate the idelay by examining the datastrobes. If you are getting > through that phase and you see datastrobes being generated, then the > commands (RAS, CAS, WE, CKE, CS) are probably OK, or at least I'd look > elsewhere. > > It's hard to tell if the address bus is OK without using a scope on the RAM. > > You can use ChipScope to see what the data looks like coming from the > RAM, but be sure that you aren't accidentally connecting to signals that > go to the IOB. The address and command signals go go IOB flipflops, but > chipscope will happily move them out of the IOB so you can look at them, > and as a bonus, you'll get lots or routing delay to confues the issues. > > If this is your own design, did you pay attention to the routing delays? > My first design spec'd that signals had to be length matched to 200ps. > In my second design, I spec'd 20ps. You could have everything correct, > but the difference in path length could prevent the calibration circuit > from aligning all the bits. > > > --- > Joe Samson > Pixel VelocityArticle: 105415
Your biggest issue is not the top surface area for the resistor site but the via space and extra routing needed to connect resistors. The vias especially will have significant routing effects. Even using a microvia blocks the path for potentially an extra signal. Conventional vias block 2 traces worth in our standard technology. BGA resistor packs whilst small tend not to have a good run of routing them and generally increase layer count to achieve the end result. John Adair Enterpoint Ltd. PeteS wrote: > John Adair wrote: > > Standards like SSTL are good for this due to the low signal swing. The > > biggest decision is if to use DCI which burns more power in the V4 or to use > > external resistors which take board area and make routing more difficult. > > > > The other decision is weither you use source synchronous clocking or a > > common clock approach. At 150 Mhz the common clock is slightly marginal > > depending on how long tracks are, speed grade, etc. unless you use some DCM > > based techniques. You can generate a clock that is offset from the common > > clock a little by using a DCM and use that as clock for register input to > > gain more time. Alternatively you can use a DCM to null out the clock to > > output time and get more margin from that. > > > > John Adair > > Enterpoint Ltd. - Home of Broaddown4. The Ultimate Virtex-4 Development > > Board. > > http://www.enterpoint.co.uk > > > > > > "Marc Reinig" <Marco@newsgroups.nospam> wrote in message > > news:44bc1fed@darkstar... > > >I have a project where I will have a large array of V4 FPGAs. Each chip is > > >intended to connect to its four orthogonal neighbors with no intervening > > >logic. I would like the number of bus connections between chips in any > > >direction in the array to be 150 (600 total I/O per chip). The connections > > >will be bi-directional. The distance between chips will be the minimum I > > >can have with sockets, heat sinks (with individual fans), good layout and > > >noise control. Some of the lines, what ever is necessary, will be used for > > >clock and framing for the bus data signals. I would like to use DDR. > > >During bus transfers, all the lines on opposite sides of the chip will be > > >operating and the other two sides will be quiescent. I'm hoping for a bus > > >clock of 150 MHz. > > > > > > > > > Comments? ;=) > > > > > > Marco > > > ________________________ > > > Marc Reinig > > > UCO/Lick Observatory > > > Laboratory for Adaptive Optics > > > > > > > > If Marc uses SSTL, and uses resistive terminators, I would agree it > takes board space, but I disagree it would make routing significantly > more difficult, except for the sheer number of devices. In a point to > point situation only a series terminator is really required for speeds > up to at least 200MHz / 400Mb/s (I've done it). > > Assuming these busses would be bidirectional, external series resistors > would [arguably, at least] actually be better in reducing EMI and > reflections than just DCI (less power too) assuming the devices are > close together (of the order of perhaps 4 inches or less). Much really > depends on the distance. I've used BGA style resistor packs that cram > more resistors into the device than can be done in multipack type SMT > devices. Apart from that, the tiny quad pack devices are particularly > sensitive to even slightly imperfect chip shooters and have a nasty > tendency to crack the resistor, particularly at the ends of the device. > > CTS corp makes a particularly nice range of devices > (http://www.ctscorp.com/components/clearone.asp) [I have no affiliation > with them except for having used the parts in the past]. > > Cheers > > PeteSArticle: 105416
Any idea of a rough price on 5V9885? It looks useful although the jitter spec would not be good enough for high end applications. ICS8442 does a lot better in that respect. John_H wrote: > I found the IDT5V9885 to be surprisingly cost effective. Intended to be a > clock generator rather than a zero delay buffer style of clock regenerator, > the filtering selections for on-chip filters appear to make the device > robust enough for serious clock cleanup. Even spread spectrum is available > within the one integrated device. I don't know if I'll get it on the > prototypes due back within the month (I'm only a contributor, not the > designer) but I sure would love to work with that part! External part count > is low, programmability is high. > > "Nico Coesel" <nico@puntnl.niks> wrote in message > news:44c140f7.1387066536@news.kpnplanet.nl... > > "John Adair" <g1@enterpoint.co.uk> wrote: > > > >>Web page with block diagram and outline spec is now on website here > >>http://www.enterpoint.co.uk/moelbryn/tarfessock1.html. > > > > How about a programmable clock source? Even better, one which has > > equal / matched lines to each FPGA so both FPGAs get the same clock. > > Multiple independant frequencies would be better. This may also be a > > good selling point for universities, crossing a clock boundary is not > > trivial in most cases. > > > > -- > > Reply to nico@nctdevpuntnl (punt=.) > > Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 105417
Hi,
Indeed, the latest version of ISE is very slow. Here is a list of
things that I did to improve them.
->More RAM, If you are working on reasonably large projects 2GB of RAM
would show considerable improvement
->RAID-0 for your installation directories and pagefiles and RAID-1 for
project files.
->If you happened to have any antivirus programs running, by all means
do disable them.
->Last but not least, you may want to try incremental synthesis on
large projects.
Ok, this may sound expensive but you may want to consider Intel Core
2(conroe) that will be available early august. Its nearly 200% faster
than your current configuration.
cheers,
kishore.
Deefoo wrote:
> A couple of years ago we've done some Spartan II development with Xilinx ISE
> tools (V5.2.03i). Now we want to do a design with a Spartan III but our
> tools are out of date or have expired. We've tried the Webpack 8.1i on a
> 3GHz Prescott with 1GB of RAM and found it very slow. Hence my question:
>
> What is a good system setup for reasonable comfortable Spartan III
> development? What kind of PC do we need and which tools?
>
> We don't want to spend too much on tools since we do FPGA only occasionally,
> but if our engineer is spending most of his time waiting for his tools to
> finish a job we may be better of spending a bit more.
>
> Thanks,
> --DF
Article: 105418Thanks to all so far. As mentined , I am busy with other parts of the design to go deeper into that at the moment. TimeQuestAnalyzer will be the next step.Article: 105419
Per Jensen skrev: > Hi! > <CUT> > > Can anyone tell me how i do this, step for step, as i am a new user of > CPLD's. - preferrably link to a online article describing how it's done. > BUMP! Anybody ??? I can't be the only one with this problem.... Regards, Per.Article: 105420
John Adair wrote: > Your biggest issue is not the top surface area for the resistor site > but the via space and extra routing needed to connect resistors. The > vias especially will have significant routing effects. Even using a > microvia blocks the path for potentially an extra signal. Conventional > vias block 2 traces worth in our standard technology. BGA resistor > packs whilst small tend not to have a good run of routing them and > generally increase layer count to achieve the end result. > > John Adair > Enterpoint Ltd. Depends on what is being routed, of course. In this particular application, the signal can go in and out very easily (1 track between balls for each ball position) and no vias at all are required. In a parallel termination case, things are different, but for a series terminator, the devices I have used work just fine with no extra layer count required. Indeed, the part manufacturers are aware of the issue that saving space for the package but providing poor access negates any advantage of the package size, so parts are appearing that have decent routing ability. Cheers PeteS > > PeteS wrote: > > John Adair wrote: > > > Standards like SSTL are good for this due to the low signal swing. The > > > biggest decision is if to use DCI which burns more power in the V4 or to use > > > external resistors which take board area and make routing more difficult. > > > > > > The other decision is weither you use source synchronous clocking or a > > > common clock approach. At 150 Mhz the common clock is slightly marginal > > > depending on how long tracks are, speed grade, etc. unless you use some DCM > > > based techniques. You can generate a clock that is offset from the common > > > clock a little by using a DCM and use that as clock for register input to > > > gain more time. Alternatively you can use a DCM to null out the clock to > > > output time and get more margin from that. > > > > > > John Adair > > > Enterpoint Ltd. - Home of Broaddown4. The Ultimate Virtex-4 Development > > > Board. > > > http://www.enterpoint.co.uk > > > > > > > > > "Marc Reinig" <Marco@newsgroups.nospam> wrote in message > > > news:44bc1fed@darkstar... > > > >I have a project where I will have a large array of V4 FPGAs. Each chip is > > > >intended to connect to its four orthogonal neighbors with no intervening > > > >logic. I would like the number of bus connections between chips in any > > > >direction in the array to be 150 (600 total I/O per chip). The connections > > > >will be bi-directional. The distance between chips will be the minimum I > > > >can have with sockets, heat sinks (with individual fans), good layout and > > > >noise control. Some of the lines, what ever is necessary, will be used for > > > >clock and framing for the bus data signals. I would like to use DDR. > > > >During bus transfers, all the lines on opposite sides of the chip will be > > > >operating and the other two sides will be quiescent. I'm hoping for a bus > > > >clock of 150 MHz. > > > > > > > > > > > > Comments? ;=) > > > > > > > > Marco > > > > ________________________ > > > > Marc Reinig > > > > UCO/Lick Observatory > > > > Laboratory for Adaptive Optics > > > > > > > > > > > > If Marc uses SSTL, and uses resistive terminators, I would agree it > > takes board space, but I disagree it would make routing significantly > > more difficult, except for the sheer number of devices. In a point to > > point situation only a series terminator is really required for speeds > > up to at least 200MHz / 400Mb/s (I've done it). > > > > Assuming these busses would be bidirectional, external series resistors > > would [arguably, at least] actually be better in reducing EMI and > > reflections than just DCI (less power too) assuming the devices are > > close together (of the order of perhaps 4 inches or less). Much really > > depends on the distance. I've used BGA style resistor packs that cram > > more resistors into the device than can be done in multipack type SMT > > devices. Apart from that, the tiny quad pack devices are particularly > > sensitive to even slightly imperfect chip shooters and have a nasty > > tendency to crack the resistor, particularly at the ends of the device. > > > > CTS corp makes a particularly nice range of devices > > (http://www.ctscorp.com/components/clearone.asp) [I have no affiliation > > with them except for having used the parts in the past]. > > > > Cheers > > > > PeteSArticle: 105421
Per Jensen wrote: > Per Jensen skrev: > > Hi! > > > <CUT> > > > > Can anyone tell me how i do this, step for step, as i am a new user of > > CPLD's. - preferrably link to a online article describing how it's done. > > > > BUMP! > > Anybody ??? I can't be the only one with this problem.... > > Regards, Per. It appears you have hit the limit on Xilinx tolerance for older parts. I was able to find a datasheet for the device, though. http://www.nalanda.nitc.ac.in/industry/appnotes/xilinx/documents/partinfo/xcr5064c.pdf The datasheet is dated Feb. 10, 2000 - which means you probably need ISE 4.x. You might try the classic webpacks, and see if they have something that goes back that far. I have a copy of 4.2i at work, so I can check back Monday with whether it supports this device or not. I suspect it will, as the datasheet specifically mentions that you can use VHDL/Verilog in addition to ABEL and schematic capture. Regards, -SethArticle: 105422
"John Adair" <g1@enterpoint.co.uk> wrote: >One thing worth considering is using logic analyser cores from Xilinx - >Chipscope or Altera - Signaltap themselves alone. If you are on a >tightish budget they are very cost effective and very good. We find we >don't usually need anything more and they are very portable, i.e. >laptop, if you need to work in the field. Downside of thsee tools is >they need resource in the FPGA. Using one of the hookups to an >external analyser does mean less resource used in the FPGA and that is >generally the only time I would use such an analyser. Even then I would >take the option, if available, of starting with an oversized FPGA to >allow the build in of an analyser function rather than plan to use an >external analyser. Still, an external analyser has a much deeper storage than available inside an fpga. And a logic analyzer doesn't need to be expensive. For instance, my ancient DAS9200 with 92C96XD card has up to 512k points per channel (at 400Ms/s). I bought it on Ebay a few years ago for 66 US Dollar. Every now and then a TLA500 or TLA510 (the little brothers of the DAS9200) unit pops up. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 105423
Hi, Can you help explain a method to print a state flow graph for any state machine design written in VHDL using either Xilinx ISE or ModelSim software? If neither has the ability of doing the function, what else software can do it? Thank you. WengArticle: 105424
Weng Tianxiang wrote:
> Can you help explain a method to print a state flow graph for any state
> machine design written in VHDL
Altera Quartus has such a viewer.
-- Mike Treseler
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