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
"Kenneth Land" <kland_not_this@neuralog_not_this.com> wrote in message news:10nckd55pitso93@news.supernews.com... > > Altera's app note "Designing with FineLine BGA Packages" indicates that it > is ok to route one (or even two!) signals between 1.0mm balls. > > My question is if anyone is actually doing this? What is the effect on > yield? > > Does Altera or anyone else offer a proven board or set of gerbers > demonstrating this routing technique? The Pulsonix software I use has a Xilinx BGA part in the library with breakout tracks which are routed between the balls. They are 5 mil width, as are the tracks on the inner layers between the vias, but there are plenty of companies who can handle that. Leon LeonArticle: 74851
"Eric Smith" <eric-no-spam-for-me@brouhaha.com> wrote in message news:qhacuiv0rr.fsf@ruckus.brouhaha.com... > I wrote: > > Why bother? There are comparable cores available that fit in an XC3S200, > > and for which you get HDL source code, not just a netlist. > > "Jaime Andrés Aranguren Cardona" <jaac@nospam.sanjaac.com> writes: > > Would you mind to tell me where from? > > http://www.opencores.org/ Hi Eric, opencores is not solution for everything, there are a few cores with full toolchain, but not so many. OR1K has full GNU toolchain support but its a real huge ip core, so if you are looking for small cpu core with full GNU toolchain support ? at opencores ? the answer is there barely is one, if you want a small CPU with GNU toolchain and SUPPORT? I dont think you find it at opencores at the moment. but, I agree, any CPU cores from startup companinies should not be considered at all if not available in HDL sources. So the MANIK does not count either as it not available in HDL source. Still room for another player! AnttiArticle: 74852
"Avin" <avin11@hotmail.com> wrote in message news:30b48c91.0410192023.42dd4d5@posting.google.com... > Hi, > > I am trying to enable commmunication between two FPGAs, both being the > Stratix 1S40 on the Nios Stratix Boards. One chip implements a > controller while the other implements a datapath. I am trying to > provide control signals to the datapath-chip from the controller-chip > and retrieve back the output from the datapath-chip back to the > controller-chip. For this, I have assigned the outputs and inputs to > the pins of the Proto connnectors on the board and used the LVTTL IO > standard. For some reason, the communication doesn't seem to take > place. Subsequently, the connection between the FPGAs is then done > through IDE cables connected to the 40 pin Proto FDCs. Any settings > that I should be aware of when attempting to enable communication > through Proto connector pins..? > > Thanks. I'm not sure if this is the source of your problem or not (assuming you have already checked trivial things and have simulated your design before going to the boards) but did you check your IDE cable? First, try to use a high quality, 80 pin IDE cable (i.e. the type used for UDMA-5 and 6 with one ground wire between each two signal wires). Also a long, parallel cable is not really the best way to make communication between two highspeed chips (it does not matter how fast your clock is, only the rising/falling edge of the signals that is controlled by the technology of the device is important). You'd better try a differntial, serial communication to have much better immunity against noise.Article: 74853
Hi, what does back-annotate assignments exactly mean? Are the assignments of the current project saved in a separate file that is a safe copy? I would be thankful for your explanation. Rgds AndreArticle: 74854
Extraced from a question by alwin <alwindotpeters.@freeler.nl> > The complete DES pipeline uses the following resources. > > Number of Slices: 1415 out of 1920 73% > Device utilization summary for this counter. > > Number of Slices: 28 out of 1920 1% > > All fine untill I place the counter in front of the pipline. > The result of the synthesis process of the complete design is: > > Number of Slices: 1972 out of 1920 102% (*) > WARNING:Xst:1336 - (*) More than 100% of Device resources are used > > ========================================== > > Am I missing something here? > This is a huge increase of used resources I can't explaine. As a wild guess, perhaps part of the DES pipeline was being optomized away without the counter there to exercise its full designed functionality? If XST figures out that a bit of logic is never used, or the result never acted upon, then it gets eliminated. What was taking the counter's place in the synthesis of the pipeline alone? Can you connect the 48 bit count value to IO's (so their value will be unkown to XST) and retry the DES part on it's own? ChrisArticle: 74855
I don't fully understand your requirements, but can you just join the two boards together using an Ethernet switch? That would probably work the best. There are usually 3 issues joining two boards together as you've suggested... 1) Power problems - make sure you have a good solid ground connection between the boards - you can measure ground bounce between the boards by grounding a scope probe on board A and measuring the ground on board B. 2) Signal Integrity - make sure your signals are terminated correctly, in particular the clock or latch signals. If you have reflections on a clock or latch, the thing won't work no matter how slow it runs. You can also mess with the slew rate and drive strength settings in Quartus. 3) Timing problems - I'm assuming you're using a synchronous interface (clock and data). On the transmitter, two techniques help here... a) Use of I/O flip-flops and b) treating the output clock as an additional data pin. If both clock and data are generated by the I/O flops, they will all effectively have equal skew. On the receive side, you should consider sampling the data on the opposite edge of the transmit clock ie sample the data in the middle not at the transitions. You should also look at the DQ/DQS structures on Stratix. They provide a dedicated structure for clocking/latching external signals, but you might not have access to them on the Stratix Board. High speed serial is not a good choice unless you have a proper connecter and routing scheme. If the 1S40 board is similar to my 1S10 board, this is not the case. Good luck, JohnArticle: 74856
Ok. So if i were to route the two clocks onto clock pins, and then use a bufgmux, would this eliminate that problem? Thanks, KeithArticle: 74857
Keith, "that problem" depends on if you care about phase or delay. But yes, if you use the global clock input pins, they have dedicated routes to the BUFG(MUX)s that are characterized and understood by the software. Austin Keith wrote: > Ok. So if i were to route the two clocks onto clock pins, and then use a bufgmux, would this eliminate that problem? > > Thanks, > > KeithArticle: 74858
thomas.bartzick@atlanticzeiser.com (Thomas Bartzick) wrote in message news:<47ce721b.0410200140.7c96f079@posting.google.com>... > Nicolas Matringe <matringe.nicolas@numeri-cable.fr> wrote in message news:<41750735.2030301@numeri-cable.fr>... > > Thomas Bartzick a écrit: > > > Hello together, > > > > > > has anyone experience with tristates in SPARTAN3-fpgas? > > > If we implement a schematic-oriented structure we won't get any > > > error-messages but only warnings and the design will be compiled fine. > > > But it seems that all our tristate outputs are driven permanently > > > (which is very bad!). > > > > I have just finished a VHDL PCI design in a Spartan3 and so far it works > > (tests are still in progress but tristate outputs are OK) > > Hello Nicolas, > > well I didn't mean, that tristates are basically a problem in SPARTAN3 > but schematic-entry->to vhdl-transformation and also specialized cores > make trouble! > > We are using a core which has been originally written vor > VIRTEX2-devices but was now tested on a SPARTAN3 on which we detected > the described phenomenons. > > A XILINX-engineer has told me that using library-primitives which > carry tristates is a bad idea, because some primitives (and so the > tristates of them) are no more supported by XILINX in SPARTAN3. > Behavioural models should be used instead! > > Ok, well any hints are welcome! Tristates can not be instantiated in Spartan 3 devices because Spartan 3 devices *DO NOT *HAVE* any tristate buffers. I believe the Virtex 4 devices are also tristate free. I belive in the past I was told that tristates were best instantiated because the tools had never been optimized for tristate synthesis. I'm not sure what that meant, but I guess they knew the end was in sight.Article: 74859
Avin wrote: > Hi, > > I am trying to enable commmunication between two FPGAs, both being the > Stratix 1S40 on the Nios Stratix Boards. One chip implements a > controller while the other implements a datapath. >[snip] To start with, you should attach a scope and look at some signals. Do they leave the sender ? Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 74860
Kenneth, Yes I do this. I get two tracks between the outer balls on the surface layer. Our PCB fab house's standard process is 4 mil tracks with 4 mil gaps. For BGAs the land size for the ball should have a diameter of half the ball pitch. The ball pitch is 1mm or 39.37 mils. So, the land diameter should be 19.69 mils, with a gap between adjacent lands of the same, 19.69mils. To get two 4 mil tracks between, with 4 mil gaps needs 20 mils. Gap track gap track gap! If you look very very closely at my boards, you'll find the outer ring of ball lands are slightly oval, to get the gap between them up from 19.69 to 20 mils! I kept the same area for the ball lands by extending the other axis a fraction, but I don't think it was really necessary. So, using this, the outer 3 rows of balls route out with no vias. Cheers, Syms. "Kenneth Land" <kland_not_this@neuralog_not_this.com> wrote in message news:10nckd55pitso93@news.supernews.com... > > Altera's app note "Designing with FineLine BGA Packages" indicates that it > is ok to route one (or even two!) signals between 1.0mm balls. > > My question is if anyone is actually doing this? What is the effect on > yield? > > Does Altera or anyone else offer a proven board or set of gerbers > demonstrating this routing technique? > > Thanks, > Ken > >Article: 74861
I would check the original design without the counter to see if a large portion was ripped out due to constant or missing inputs. Obviously the counter itself wouldn't account for the extra slices. Look at the map report from the non-counter and see what got ripped out. alwin <alwindotpeters.@freeler.nl> wrote in message news:<r7hcn0d6k9nok5co7qmuhs5qoi9pk5kgci@4ax.com>... > Hello, > > I'm playing with the spartan3 starter KIT. > > One of my goals was to implemenet a pipelined DES design for cracking > a good old single des-challenge. The complete DES pipeline uses the > following resources. > > Device utilization summary: > --------------------------- > > Selected Device : 3s200ft256-5 > > Number of Slices: 1415 out of 1920 73% > Number of Slice Flip Flops: 1081 out of 3840 28% > Number of 4 input LUTs: 2342 out of 3840 60% > Number of bonded IOBs: 65 out of 173 37% > Number of GCLKs: 1 out of 8 12% > > > ========================================== > > Now I need to step through a 48 bit key space (I know the other 8 > bits) .The code for a simple 48 bit counter: > >entity keygen is port > >( > > CLK: in STD_LOGIC; > > RESET: in STD_LOGIC; > > COUNT: inout STD_LOGIC_VECTOR(1 to 48) > >); > >end keygen; > > > >architecture Behavioral of keygen is > > > >begin > > > >process (CLK, RESET) > >begin > > if RESET='1' then > > COUNT <= x"000000000000"; > > elsif CLK='1' and CLK'event then > > COUNT <= COUNT + 1; > > end if; > > > >end process; > > > > > >end Behavioral; > > > Device utilization summary for this counter. > --------------------------- > > Selected Device : 3s200ft256-5 > > Number of Slices: 28 out of 1920 1% > Number of Slice Flip Flops: 48 out of 3840 1% > Number of 4 input LUTs: 48 out of 3840 1% > Number of bonded IOBs: 49 out of 173 28% > Number of GCLKs: 1 out of 8 12% > > ========================================== > > All fine untill I place the counter in front of the pipline. > The result of the synthesis process of the complete design is: > > Device utilization summary: > --------------------------- > > Selected Device : 3s200ft256-5 > > Number of Slices: 1972 out of 1920 102% (*) > Number of Slice Flip Flops: 1752 out of 3840 45% > Number of 4 input LUTs: 3116 out of 3840 81% > Number of bonded IOBs: 65 out of 173 37% > Number of GCLKs: 1 out of 8 12% > > WARNING:Xst:1336 - (*) More than 100% of Device resources are used > > ========================================== > > Am I missing something here? > This is a huge increase of used resources I can't explaine. > > Any help/explanation is welcome. > > regards > AlwinArticle: 74862
On 20 Oct 2004 08:49:13 -0700, cs_posting@hotmail.com (Chris Stratton) wrote: >Extraced from a question by alwin <alwindotpeters.@freeler.nl> > >> The complete DES pipeline uses the following resources. >> >> Number of Slices: 1415 out of 1920 73% >> Device utilization summary for this counter. >> >> Number of Slices: 28 out of 1920 1% >> >> All fine untill I place the counter in front of the pipline. >> The result of the synthesis process of the complete design is: >> >> Number of Slices: 1972 out of 1920 102% (*) >> WARNING:Xst:1336 - (*) More than 100% of Device resources are used >> >> ========================================== >> >> Am I missing something here? >> This is a huge increase of used resources I can't explaine. > >As a wild guess, perhaps part of the DES pipeline was being optomized >away without the counter there to exercise its full designed >functionality? If XST figures out that a bit of logic is never used, >or the result never acted upon, then it gets eliminated. > >What was taking the counter's place in the synthesis of the pipeline >alone? Can you connect the 48 bit count value to IO's (so their value >will be unkown to XST) and retry the DES part on it's own? > >Chris Well, maybe it is not the counter causing this problem. The same problems occur when changing other parts of the code (changing # IO's at the top level) Since this is my first vhdl/fpga project, I need to gain more knowledge about vhdl and synthesis to understand whats going on. And come back later to this board if the problem still exists. Darn... I 'just can't wait to see my 99 dollar device to crack 250M DES keys/s. (estimated speed..) AlwinArticle: 74863
"Brian Davis" <brimdavis@aol.com> wrote in message news:a528ffe0.0410200342.638dedb0@posting.google.com... <snipped very informative stuff> > > The other concern I have with the Xilinx IBIS models is > that they're still using an ancient version of IBIS (2.1), > which doesn't support some of the newer IBIS features such > as differential input parasitics. ( Which explains the lack > of IBIS models for the _DT terminators in the V2Pro ) I see in XAPP475 they say that "Unfortunately, IBIS 3.2 still is not widely supported by simulators.". It wouldn't hurt to publish new IBIS3.2 or even 4.0 files alongside the old ones though! Thanks for a very informative post, much appreciated. Best, Syms.Article: 74864
Johan Bernspćng wrote: > > rickman wrote: > > > WOW! I have no idea what is going on in 100 hours. I am simulating > > about 800 LEs and 5 blocks of memory, plus a test bench and it takes > > less than a minute per 5 uS of simulation. > > > > Well, it's a quite large design sampling the input at 200 MHz (from an > ADC), CIC filters, LP FIRs, CORDIC, BP FIRs etc. I.e. lots of > calculations for my poor ModelSim. > > Earlier in the design cycle I've been trying to avoid simulations due to > the complexity of the system. But I gave it a try anyway since I was > occupied with some other stuff for a few days... Certainly you have shown that you *can* get by without simulation, but I find it hard to believe that this is more efficient than simulating. In simulation you can simulate any or all of a design (you could have tested your design in blocks) and access *any* signal in the simulation. Plus a simulation can make it clear whether a problem is logic or speed related. Of course a static timing analysis would identify any speed issues, but you can simulate without timing before even doing a place and route. But to each his own... :) -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 74865
Antti Lukats wrote: > > NIOX is done by me (3 evnings workload) - its completly clean version > written from scratch. It has no pipeline but if running from brams can run > about 1 clock instruction except load instructions what is way faster than > NIOSII/e > > I am testing NIOS-II/uCLinux platform simulator at the moment if that is > done then I know how to verify NIOX as well, next step would be NIOX/uCLinux > SoC Have you done any place and routes to get an idea of the speed and LE count? Or was that already posted and I missed it? I believe Altera has a version of the NIOS-II that is only 600 LEs. That would make me very happy if I could put it in an ACEX as well as a Spartan. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 74866
"Antti Lukats" <antti@case2000.com> writes: > opencores is not solution for everything, there are a few cores with full > toolchain, but not so many. OR1K has full GNU toolchain support but its a > real huge ip core, so if you are looking for small cpu core with full GNU > toolchain support ? at opencores ? the answer is there barely is one, if you > want a small CPU with GNU toolchain and SUPPORT? You don't get support for ANYTHING without paying for it. But there are multiple cores for which there is a full GNU toolchain. aeMB (32-bit) and several of the AVR cores (8-bit) come to mind, but there are other choices.Article: 74867
Johan, Yeah, I did a very similar project to you, lots of cascaded DSP blocks. My DSP blocks were homespun, so I did initially functionally simulate them separately, but not especially thoroughly, while my hardware was being built. When the hardware turned up, I mostly used Chipscope to fault find. Your point about using a real input source for the blocks is a key advantage of Chipscope, especially in computationally intense apps like DSP. Chipscope revealed several 'design opportunities' when I tested with real signals, that simulation missed because of the limited time and effort available to make test vectors. Chipscope is also a winner for soft processors. It's easy to use Data2mem to upload new code to a BRAM, and debug your code in Chipscope without needing a P&R cycle. Cheers, Syms. "Johan Bernspćng" <xjohbex@xfoix.se> wrote in message news:cl52bs$t2d$1@mercur.foi.se... Symon wrote: > "Johan Bernspćng" <xjohbex@xfoix.se> wrote in message > news:cl2g6r$fn7$1@mercur.foi.se... > > >>Well, it's a quite large design sampling the input at 200 MHz (from an >>ADC), CIC filters, LP FIRs, CORDIC, BP FIRs etc. I.e. lots of >>calculations for my poor ModelSim. > > > Of course, you simulated each of these blocks separately to verify they > worked? ;-) > Cheers, Syms. > > > Actually, no I didn't. I used ChipScope and a real input source to the system. Since the filter blocks are from CoreGen, as well as the CORDIC, I wouldn't get more information about the internal signals from a simulation as I get from ChipScope. CheersArticle: 74868
Eric Smith wrote: > "Antti Lukats" <antti@case2000.com> writes: > >>opencores is not solution for everything, there are a few cores with full >>toolchain, but not so many. OR1K has full GNU toolchain support but its a >>real huge ip core, so if you are looking for small cpu core with full GNU >>toolchain support ? at opencores ? the answer is there barely is one, if you >>want a small CPU with GNU toolchain and SUPPORT? > > > You don't get support for ANYTHING without paying for it. And conversely, we've all paid for support and not gotten anything at times (: > But there are multiple cores for which there is a full GNU toolchain. > aeMB (32-bit) and several of the AVR cores (8-bit) come to mind, but > there are other choices.Article: 74869
"Moti Cohen" <moti@terasync.net> wrote in message news:c04bfe33.0410200517.391ab8d9@posting.google.com... > my static timing analisys looks o.k. (at least the paths that i've > constrained). and I realy dont know where to start looking. > I checked my design over and over for "bad code" parts but didnt found > anything that might explain this. What is your background is FPGA design? This might be teaching you to suck eggs, but.... Ideally you want your whole design to be written synchronously off one clock. The only constraints you will then need are 1 for the clock and for input/output timing. If you have ripple/gated clocks the timing analysis tools can't do a proper analysis on what's actually going to happen and you're likely to have a lot of clock races etc. Nial. ------------------------------------------------ Nial Stewart Developments Ltd FPGA and High Speed Digital Design Cyclone Based 'Easy PCI' proto board www.nialstewartdevelopments.co.ukArticle: 74870
You could also allow XST to read in the "module" NGC with -read_cores option. Xst will read in your NGC to recognize the logic and infer IO appropriately to the ports that need IO buffers. Sean Durkin wrote: > Laurent Gauch wrote on 20.10.2004 13:12: > >> Hi all, >> >> I am finishing my PCI core. >> >> I want to do from XST an .ngc file of my PCI core. >> The goal is to map IO buffers for all the PCI signal and to let other >> signals without IO buffer mapping. >> >> If I use the XST command line -iobuf , I can only enable or disable >> the use of IO Buffer on all the port of the entity. >> >> Any advice ? > > The only way to do this I can think of is to disable automatic IOBUF > insertion in XST and manually instantiate IO buffers for those signals > you need them for in your VHDL-code. With a few > for...generate-statements it shouldn't even be a whole lot of code. > > cu, > Sean -- / 7\'7 Paulo Dutra (paulo.dutra@xilinx.com) \ \ ` Xilinx hotline@xilinx.com / / 2100 Logic Drive http://www.xilinx.com \_\/.\ San Jose, California 95124-3450 USAArticle: 74871
In my experience, FSM's generally stop working when there are asynchronous inputs. Note that in XST you need to try REALLY hard to end up with FSM's synthesized any way other than one-hot. When an asynchronous input affects the next state decision in the FSM, you can go to "zero-hot" or "more-than-one-hot" on a state after the async input doesn't meet setup and hold requirements. This can also happen if the FSM comes out of reset asynchronously. There was a recent thread about this... moti@terasync.net (Moti Cohen) wrote in message news:<c04bfe33.0410200517.391ab8d9@posting.google.com>... > Hello all, > > first a little background .. > I'm currently working on a fpga design (using VHDL) and using > the Xilinx spartan IIE fpga (xc2s400e) chip. > my design size is about 1300 slices (about third of the chip > capacity). > My problem is as follow : > sometimes when I change my top design and then re-synthisizes it, some > "parts" of my code is not working properly i.e. - some of my fpga > blocks are working as usuall and some dont (e.g. FSMs). > this appens not only for large code changes, sometimes it happens when > I "just" change an output pin to be '0' instead of '1' (a very minor > change). > my static timing analisys looks o.k. (at least the paths that i've > constrained). and I realy dont know where to start looking. > I checked my design over and over for "bad code" parts but didnt found > anything that might explain this. > > I would realy like to know if some of you have expeienesd something > similar in the past and if not maybe someone can give me a tip to > start with.. > > thanks in advance, Moti.Article: 74872
Hi William, Did you include a timing constraint of some ns on your clock in the ucf file? - Vic William wrote: > There is no Fmax reported when I instantiated a DSP48 with internal > input and output registers turned on. Anyone have any ideas, why this > happened? > > Thanks.Article: 74873
Hi Kedar,
Partial Reconfiguration can definitely be used
on most Xilinx Virtex Series FPGA's - especially in the latter
ones. This should be documented under "ICAP Port" in the user
guide or the chip documentation available at www.xilinx.com.
We designed the chips such that sections of your
chip can remain active as normal while other sections are being
reconfigured. For more practical experience with actually
using it - perhaps other members of comp.arch.fpga can
share their experiences.
- Vic
"Kedar P. Apte" wrote:
> Hello
>
> I need some practical info on
> has any body used Xilinx Vertex series of FPGAs for any project
> involving active partial reconfiguration
>
> I mean to say that if a part of FPGA is working then can we
> reconfigure another part of the FPGA and make it work
>
> Rgds
> Kedar
Article: 74874Hi Everyone, I have generated a VIO core using the xilinx Chipscope Pro Generator. I move my design into xilinx ISE. For some reason, when i look at my clock signals, it thinks that signals going into my VIO core are clock signals. Is this just the way the vio core works or is there something wrong? Thanks, Andy Wilkins
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