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
"Weng Tianxiang" <wtxwtx@gmail.com> wrote in message news:1178734641.089317.12310@n59g2000hsh.googlegroups.com... > On May 9, 10:32 am, Chris <c@c> wrote: >> austin wrote: >> > 1. Learn spice >> > 2. Use spice. >> >> 3. The spice must flow! >> >> (sorry, couldn't resist ;-) > > Hi Chris, > What does 'flow' mean? > > Weng > I believe this was an attempt at a literary reference to the "Dune" science fiction novel(s). Not quite the universal joke.Article: 119026
> It should unroll the loop, and there is therefore nothing undefined > about the clk.... but yet ModelSim says that 'EVENT requires a static > prefix.... anyone know why? how to get around it? thanx My guess is that there might be some issue with the sensitivity list. I assume you have an end loop statement. I got the same results: "requires a static signal prefix". I had better results using a generate statement: s_chan_gen: for k in 0 to 15 generate process (reset_delayed, ch_clk_div_int(k)) begin if reset_delayed = '1' then reset_chan_Q_int(k) <= '1'; reset_chan_QQ(k) <= '1'; elsif ch_clk_div_int(k)'EVENT AND ch_clk_div_int(k)='1' then reset_chan_Q_int(k) <= '0'; reset_chan_QQ(k) <= reset_chan_Q_int(k); end if; reset_chan_Q(k) <= reset_chan_Q_int(k); end process; end generate; Here there is only one clock signal for each generated process. Regards, Brad Smallridge AiVisionArticle: 119027
Paul schrieb: > Can't figure it out... Why cant this compile: > > S_chan0_clk : process (reset_delayed, ch_clk_div_int) > begin > for k in 0 to 15 loop > test_case := ch_clk_div_int(k); > if reset_delayed = '1' then > reset_chan_Q(k) <= '1'; > reset_chan_QQ(k) <= '1'; > elsif ch_clk_div_int(k) = '1' AND ch_clk_div_int(k)'EVENT then > reset_chan_Q(k) <= '0'; > reset_chan_QQ(k) <= reset_chan_Q(k); > end if; > end process; move that for-loop outside of this process and change it to a for-generate. (And don't forget the "end generate;" - you have forgotten the "end loop;") my_gen_label : for k in 0 to 15 generate -- your process here end generate; Note that not all synthesis tools accept the a vector element inside a rising_edge() expression. E.g. Synopsys Design Analyzer does not accept "rising_edge(ch_clk_div_int(k))". This is pretty annoying. RalfArticle: 119028
I recently switched over to ISE 9.1 and I noticed a problem where ISE won't recognize the design hierarchy. Thinking that it might be something specific to my design, I tried the example design files provided with one of the Xilinx cores and lo and behold the design hierarchy is incorrect again. Eventually I figured out that it is the synthesis directives (e.g. "// synthesis syn_noclockbuf = 1") that seem to cause this problem. When I remove the synthesis directives, ISE 9.1 recognizes the hierarchy correctly. This behavior is repeatable: 1. When I remove the synthesis directives, the hierarchy appears correctly. 2. When I include the synthesis directives, the hierarchy disappears. Has anyone else noticed something similar or have any insight into fixing this problem?Article: 119029
Herbert Kleebauer wrote: > steve.lass@xilinx.com wrote: > > >>There are a few programs that we could open-source, but they >>only have a few engineers working on them, so it would not save >>resources since we have to manage the open-source projects. >> >>The bigger applications like ProjNav and XPS are much more >>device/Xilinx specific than most of you are implying so I don't >>see an easy solution there either. XST is very device specific and >>this is one of the applications that starts their work over a year >>ahead of a new device introduction. > > > Why can't Xilinx make available the complete specification of > the configuration bitstream for a single, already obsolete > device, maybe the original 5/3.3V Spartan XCS40/XCS40XL chip > together with the guarantee to deliver this chips for at least > 20 years. Then the open source community had a basis to > develop their own design tools at least for this FPGA. And I suppose > there are many smaller projects for which such an old chip is more > than sufficient. Couple of commercial counter-points: Xilinx like to control the EOL process, and the ultimate 'brick wall' in this EOL is usually the close of a FAB line. So too much activity on very old devices is not a good thing. Another risk, is if the Open Source direction gets smarter, and develops customer demand for the features, on NEW FPGAs, that fragments Xilinx's efforts. > What would you say, if a CPU manufacturer doesn't make available > the processor documentation (instruction set, instruction encoding). > He only gives you a C compiler to design your software and > anything below is the secret of the company. Nobody would buy such > a processor, but that's exactly the situation with FPGA's. A better analogy could be Microcontroller Programming and Debug. It is now quite rare to find a closed-algorithm on the uC programming front, as the Vendors realise production programming is widely used. Even Debug is trending to more open, as vendors realise there is actually little real risk in this. In many ways the FPGA market is sluggish - they were very slow to move from proprietary config memory, to industry std parts. They are only on the first steps of waking up to, and using, multi die design flows. Lattice do have OpenSource SoftCPU efforts, and they are being well received. -jgArticle: 119030
On May 9, 4:00 pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > In many ways the FPGA market is sluggish - they were very slow to move > from proprietary config memory, to industry std parts. > They are only on the first steps of waking up to, and using, > multi die design flows. So sluggish, that reconfigurable computing may be completely dead shortly, unless these guys can open up in a big way. The presentation at FCCM by Los Alamos benchmarking performance, system, and development costs on FPGA, Cell, and GPU's left FPGA's dead last by a factor of 3 behind Cell performance and costs. While the work was done on a XC2VP50, a several year old product, as compared to a hot off the press Cell processor, is does show that Xiinx is close to losing high end applications where they have been a star ... and with that some serious high end revenue, rather than capitalizing on it's strengths while it still has a potential commodity market appeal, and using those dollars to refine that market penitration. While the Virtex 5 parts have significant promise, sluggish acceptance of the market will certainly kill it, as will the high prices from low volumes that can easily be corrected by facilitating acceptance as a comodity and supporting the market properly for these applications.Article: 119031
jetmarc@hotmail.com wrote: > Hi. > > I'm debugging an issue with my board. The issue surfaces when several > components interact, and I'm not able to reproduce the problem in a > pure simulation environment. > > I heard that Chipscope is a powerful tool for this type of debugging. > However, my board has JTAG functionality through a custom interface > (not a Xilinx cable). > > Is it possible to make Chipscope work with my custom interface? I use > Windows and have C/C++ development tools available. I already made an > XSVF player to program my board via the custom interface. > > Regards, > Marc > > PS: My alternative is to reinvent the wheel and add a trace buffer and > trigger logic to my design, and write a tiny readout tool and a > visualization filter. I started with this already, but struggle > because if Chipscope were compatible I would save time and get the > better tool. > I'm not sure if I understand the situation completely, but I can tell you I've used ChipScope with the WildCard-4, which has no JTAG interface; just some general-purpose I/O pins available on an external connector. Some guys I work with got around that problem in the following manner. They replicated the functionality of the BSCAN_VIRTEX4 primitive, making a version that works in the fabric. This version doesn't have to connect to the internal JTAG bus; they connected it to the general-purpose I/O pins instead. Then they modified the EDIF for the Chipscope ICON core to replace the BSCAN_VIRTEX4 primitive with their own. Then they made a custom connector that connected the Xilinx JTAG cable to the Wildcard's port. It looks like it might have been a pain but it certainly helped me to debug. Maybe you could do something similar--you still have to use the Xilinx JTAG cable, but you don't have to connect it to the Xilinx JTAG port. I don't know if this works in your situation. -KevinArticle: 119032
Herbert Kleebauer wrote: > What would you say, if a CPU manufacturer doesn't make available > the processor documentation (instruction set, instruction encoding). > He only gives you a C compiler to design your software and > anything below is the secret of the company. It's been done. The "Neuron" processor that Motorola and Toshiba made for Lonworks. It looked like it would be a good chip for some of my designs at the time, but since the instruction set, etc. was secret, I decided against using it, as did other engineers I knew. > Nobody would buy such a processor, > but that's exactly the situation with FPGA's. Obvioiusly some people would buy such a processor, since some did. The situation with FPGAs is more complex. Most people don't even want to know the details of the bitstream, and are satisfied with proprietary tools.Article: 119033
Andreas Ehliar wrote: > Personally I'd rather have effort spent on a high quality emacs-mode for > RTL development. VHDL mode is good, Verilog mode is good, but there is > a _huge_ opportunity to improve the current situation. I'm not sure what you expect of a "high quality emacs-mdoe for RTL" that isn't already there, but that sounds like an issue for the existing emacs user community, not something I'd expect Xilinx to do. >I'd also like to > see a more "standardized" makefile based build system so that not every > developer has to reinvent that particular wheel. Especially since the > available parts (command line tools) are sometimes cumbersome to fit into > the wheel (makefile). I agree with you there. > For example, if we show that we can build a high quality synthesizer > frontend that has about the same performance as XST, Aside from not supporting VHDL, how far is Icarus from that?Article: 119034
fpga_toys@yahoo.com wrote: > On May 9, 4:00 pm, Jim Granville <no.s...@designtools.maps.co.nz> > wrote: > >>In many ways the FPGA market is sluggish - they were very slow to move >>from proprietary config memory, to industry std parts. >>They are only on the first steps of waking up to, and using, >>multi die design flows. > > > So sluggish, that reconfigurable computing may be completely dead > shortly, unless these guys can open up in a big way. The presentation > at FCCM by Los Alamos benchmarking performance, system, and > development costs on FPGA, Cell, and GPU's left FPGA's dead last by a > factor of 3 behind Cell performance and costs. How did the GPUs stack up in this comparison ? > While the work was > done on a XC2VP50, a several year old product, as compared to a hot > off the press Cell processor, is does show that Xiinx is close to > losing high end applications where they have been a star ... and with > that some serious high end revenue, rather than capitalizing on it's > strengths while it still has a potential commodity market appeal, and > using those dollars to refine that market penitration. > > While the Virtex 5 parts have significant promise, sluggish acceptance > of the market will certainly kill it, as will the high prices from low > volumes that can easily be corrected by facilitating acceptance as a > comodity and supporting the market properly for these applications. FPGA sales growth is not stellar, and if you compare them with the fabless averages, FPGAs are pulling down the numbers. High speed serial links do seem to be one area FPGAs can have a safe niche. Altera ahve new devices there, as do Lattice. - so you might find a system designed with (many) Cell processors, liked with FPGA Serial backplanes, could be the best pathway for reconfigurable computing ? -jgArticle: 119035
On 2007-05-09, Eric Smith <eric@brouhaha.com> wrote: > I'm not sure what you expect of a "high quality emacs-mdoe for RTL" that > isn't already there, but that sounds like an issue for the existing emacs > user community, not something I'd expect Xilinx to do. My idea is that the VHDL/Verilog mode should parse the RTL source code so that it is truly able to understand the design. Not only could the hierarchy be shown (something I think VHDL mode already can do) but the emacs mode could then be able to highlight potentially dangerous situations that warrant extra thought such as for example: * Clock domain crossings * Latches * Potentially unsafe use of <= and especially = in Verilog. In addition, it would be nice if VHDL and Verilog mode was integrated so that mixed language designs didn't confuse the editor once this framework is in place. I would really like to be able to use a keyboard shortcut to trace a signal to where it is assigned in a design or to all the places where it is used. I don't expect Xilinx to do this though, I merely wanted to point out that there is a huge potential for improvement here. Improvements which would help all RTL designers (who use emacs) and not only Xilinx users. /AndreasArticle: 119036
On 2007-05-09, Eric Smith <eric@brouhaha.com> wrote: > Aside from not supporting VHDL, how far is Icarus from that? The last time I checked it wasn't able to synthesize almost any designs of mine due to the following: always @* begin outputsignal <= somedefaultvalue; if(foo) begin outputsignal <= someothervalue; end end IIRC, in this case it complained that there was no else part of the if statement. (It could simulate the design but not synthesize it.) I guess I should file a bug report for it unless it has been fixed in the latest version. /AndreasArticle: 119037
I'm restricted to 30Mhz LVDS clock input. From this, I need to generate 240Mhz to be used internally. Restriction comes an ASIC that I'm interfacing to. What options do I have here? Based on what I see in ds302 by Xilinx, I haven't found a clean (or, any) solution. Minimum clock speed I need is 32Mhz for DCM. If the min speed weren't an issue, I could cascade two DCMs - 4x and 2x - to get 8x. (I know, cascading is not ideal due to jitter). Am I stuck? The 30Mhz clock is actually for data coming in at 240Mhz rate. Is there any way out of this?Article: 119038
Use Frequency Synthesis mode driving the Fx output. Then you do not have the min input frequency limitation, and you can multiply and divide (simultaneously!) the input frequency by any integer up to 32. So you just multiply by 8 and divide by 1 to get 240 MHz. Peter Alfke, Xilinx Applications, from home On May 9, 9:43 pm, fastgreen2...@yahoo.com wrote: > I'm restricted to 30Mhz LVDS clock input. From this, I need to > generate 240Mhz to be used internally. Restriction comes an ASIC that > I'm interfacing to. What options do I have here? > > Based on what I see in ds302 by Xilinx, I haven't found a clean (or, > any) solution. Minimum clock speed I need is 32Mhz for DCM. If the > min speed weren't an issue, I could cascade two DCMs - 4x and 2x - to > get 8x. (I know, cascading is not ideal due to jitter). > > Am I stuck? The 30Mhz clock is actually for data coming in at 240Mhz > rate. > > Is there any way out of this?Article: 119039
Hi, everyone I've been stuck on this problem for a couple of days, and still couldnt figure out how this happen. I have an XPS/ISE combined project. The part of ISE project is a hardware accelerator which is connected to powerpc system generated by XPS via dsocm. After I merged both projects in ISE and tried to implement it to fpga, the weird thing happened!!! My logic was almost removed by 25% after XIlinx Map. Firstly, I synthesized the whole project using XST. The synthesis report looks pretty right, about 30% of slice are consumed. And then I moved on to do translation, the report looks more or less the same. But after mapping, the logic utilization reduces to only 5%!!! Almost everything inside the hardware accelerator are removed. At the beginning, I assume there must be something wrong with the connection between the ppc_subsystem and the hardware accelerator. I triple checked the top level vhdl code but couldnt find anything wrong. I tried many many times re-mapping, I still got the 5% logic left. The hardware accelerator can function correcly and was verified by modelsim and can be correctly PAR, the logic utilization of which is around 30%. The ppc_subsystem can be correctly PAR as well, and consumes 4% of total fpga fabric. Both things can be synthesized but once after MAP, the total logic has been removed by 25%. I really cannot understand why the logic be removed even everything is in good connection. Hardware Accelerator Only --------------------------------------------------------------------------------------------------- Device Utilization Summary Logic Utilization Used Available Utilization Note(s) Number of Slice Flip Flops 8,485 27,392 30% Number of 4 input LUTs 5,421 27,392 19% Logic Distribution Number of occupied Slices 4,859 13,696 35% Number of Slices containing only related logic 4,859 4,859 100% Number of Slices containing unrelated logic 0 4,859 0% Total Number 4 input LUTs 6,387 27,392 23% Number used as logic 5,421 Number used as a route-thru 109 Number used for Dual Port RAMs 228 Number used as Shift registers 629 Number of bonded IOBs 147 556 26% IOB Flip Flops 1 Number of PPC405s 0 2 0% Number of Block RAMs 29 136 21% Number of MULT18X18s 48 136 35% Number of GCLKs 2 16 12% Number of GTs 0 8 0% Number of GT10s 0 0 0% Number of RPM macros 20 Total equivalent gate count for design 2,281,651 Additional JTAG gate count for IOBs 7,056 ------------------------------------------------------------------------------------------------ Hardware Accelerator + PPC_subsystem ------------------------------------------------------------------------------------------------ Device Utilization Summary Logic Utilization Used Available Utilization Note(s) Number of Slice Flip Flops 1,370 27,392 5% Number of 4 input LUTs 1,486 27,392 5% Logic Distribution Number of occupied Slices 1,437 13,696 10% Number of Slices containing only related logic 1,437 1,437 100% Number of Slices containing unrelated logic 0 1,437 0% Total Number 4 input LUTs 1,796 27,392 6% Number used as logic 1,486 Number used as a route-thru 68 Number used for Dual Port RAMs 188 Number used as Shift registers 54 Number of bonded IOBs 4 556 1% IOB Flip Flops 2 Number of PPC405s 2 2 100% Number of JTAGPPCs 1 1 100% Number of Block RAMs 48 136 35% Number of GCLKs 2 16 12% Number of DCMs 1 8 12% Number of GTs 0 8 0% Number of GT10s 0 0 0% Total equivalent gate count for design 3,201,070 Additional JTAG gate count for IOBs 192 ----------------------------------------------------------------------------------------------------------------- Has anyone experienced this before? Thanks in advance, YaoArticle: 119040
In article <f1s3h6$p9v2@cnn.xsj.xilinx.com>, Ben Jones <ben.jones@xilinx.com> wrote: > First of all, what exactly is the scope of this "open source ISE" supposed > to be? If it's just a vendor-agnostic IDE for designing FPGAs, then it > sounds like a trivial wrapper around the proprietary synthesis and back-end > tool flows. Most serious FPGA developers already have their own makefiles > and associated infrastructure that eases the portability of their design > from one vendor's device to another's. At which point, slapping a sparkly > GUI on top of it is not a high priority for them. If "everyone agrees the Xilinx ISE is crap and has to build their own tools to get any real work done" (yes, I'm paraphrasing your words a bit :-) ) then that looks like a good opportunity for open source. Rather than each developer effectively cobbling together their own version of an IDE, you can make the Xilinx IDE open source and people can fix things. A "sparkly GUI" can be nice, but many people would be satisfied with a "more usable GUI that doesn't corrupt the opaque binary project file every few days requiring it to be tediously re-constructed using an interface that doesn't even let you select multiple files to move them into a library." It's a start. -- David M. Palmer dmpalmer@email.com (formerly @clark.net, @ematic.com)Article: 119041
hello I need to design DVI over FIBER my idea to do as follow DVI to data then to FPGA the FPGA will use memory sunc SDRAM or DDRAM will send info via phy and the same on RX side I need help with FPGA please help i am on msn or skype avcohen or applicau2 Albert 818 2558700Article: 119042
On 2007-05-10, Andreas Ehliar <ehliar@lysator.liu.se> wrote: > On 2007-05-09, Eric Smith <eric@brouhaha.com> wrote: >> Aside from not supporting VHDL, how far is Icarus from that? > > The last time I checked it wasn't able to synthesize almost any > designs of mine due to the following: > > always @* begin > outputsignal <= somedefaultvalue; > if(foo) begin > outputsignal <= someothervalue; > end > end I just checked 0.8.4 and that version seems capable of synthesizing this type of construct. I couldn't synthesize other parts of a certain design though. (I'm using the OR1200 processor as a test case now.) /AndreasArticle: 119043
On 2007-05-10, John Adair <g1@enterpoint.co.uk> wrote: > We have just posted the schematics to this product and given some more > details on I/O counts on our engineering website. Details are here > http://www.enterpoint.co.uk/moelbryn/darnaw1.html. Do you by any chance have the same kind of information available for the Craignell modules? (I'd like to know what pins are used for ground and 5V to see if I would be able to use this kind module to repair/improve some old computers I have in storage.) /AndreasArticle: 119044
On 10 Mai, 01:02, Kevin Neilson <kevin_neil...@removethiscomcast.net> wrote: > jetm...@hotmail.com wrote: > > Hi. > > > I'm debugging an issue with my board. The issue surfaces when several > > components interact, and I'm not able to reproduce the problem in a > > pure simulation environment. > > > I heard that Chipscope is a powerful tool for this type of debugging. > > However, my board has JTAG functionality through a custom interface > > (not a Xilinx cable). > > > Is it possible to make Chipscope work with my custom interface? I use > > Windows and have C/C++ development tools available. I already made an > > XSVF player to program my board via the custom interface. > > > Regards, > > Marc > > > PS: My alternative is to reinvent the wheel and add a trace buffer and > > trigger logic to my design, and write a tiny readout tool and a > > visualization filter. I started with this already, but struggle > > because if Chipscope were compatible I would save time and get the > > better tool. > > I'm not sure if I understand the situation completely, but I can tell > you I've used ChipScope with the WildCard-4, which has no JTAG > interface; just some general-purpose I/O pins available on an external > connector. Some guys I work with got around that problem in the > following manner. They replicated the functionality of the > BSCAN_VIRTEX4 primitive, making a version that works in the fabric. > This version doesn't have to connect to the internal JTAG bus; they > connected it to the general-purpose I/O pins instead. Then they > modified the EDIF for the Chipscope ICON core to replace the > BSCAN_VIRTEX4 primitive with their own. Then they made a custom > connector that connected the Xilinx JTAG cable to the Wildcard's port. > It looks like it might have been a pain but it certainly helped me to > debug. Maybe you could do something similar--you still have to use the > Xilinx JTAG cable, but you don't have to connect it to the Xilinx JTAG > port. I don't know if this works in your situation. -Kevin- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - Ha this is the another part of the reverse engineering, this I also have done eg BSCAN fully in FPGA fabric and using the regular io for extra BSCAN JTAG TAP. but this was not the issue for the OP, he needs custom JTAG adapter to be used with regular FPGA jtag pins AnttiArticle: 119045
We have just posted the schematics to this product and given some more details on I/O counts on our engineering website. Details are here http://www.enterpoint.co.uk/moelbryn/darnaw1.html. I am still interested in feedback on this product as we start the design of Darnaw2 in the next few weeks so it is your chance to influence what we produce. John Adair Eneterpoint Ltd.Article: 119046
yao.sics@gmail.com wrote: > Hi, everyone > > I've been stuck on this problem for a couple of days, and still > couldnt figure out how this happen. > I have an XPS/ISE combined project. The part of ISE project is a > hardware accelerator which is connected to powerpc system generated by > XPS via dsocm. After I merged both projects in ISE and tried to > implement it to fpga, the weird thing happened!!! My logic was almost > removed by 25% after XIlinx Map. Firstly, I synthesized the whole This looks a bit like the problem that I am having: http://www.fpga-faq.com/archives/118400.html#118424 Regards, Sietse Achterop CS department, University of Groningen, The Netherlands sietse@cs.rug.nlArticle: 119047
On May 8, 5:14 pm, jetm...@hotmail.com wrote: > Hi. > > I'm debugging an issue with my board. The issue surfaces when several > components interact, and I'm not able to reproduce the problem in a > pure simulation environment. > > I heard that Chipscope is a powerful tool for this type of debugging. > However, my board has JTAG functionality through a custom interface > (not a Xilinx cable). > > Is it possible to make Chipscope work with my custom interface? I use > Windows and have C/C++ development tools available. I already made an > XSVF player to program my board via the custom interface. > > Regards, > Marc > > PS: My alternative is to reinvent the wheel and add a trace buffer and > trigger logic to my design, and write a tiny readout tool and a > visualization filter. I started with this already, but struggle > because if Chipscope were compatible I would save time and get the > better tool. You can try using Synplicity Identify tool as it supports the custom cables too. Debugging is much more easy as it is done at the RTL levelArticle: 119048
On 10 May, 07:15, Andreas Ehliar <ehl...@lysator.liu.se> wrote: > On 2007-05-10, John Adair <g...@enterpoint.co.uk> wrote: > > > We have just posted the schematics to this product and given some more > > details on I/O counts on our engineering website. Details are here > >http://www.enterpoint.co.uk/moelbryn/darnaw1.html. > > Do you by any chance have the same kind of information available for > the Craignell modules? (I'd like to know what pins are used for > ground and 5V to see if I would be able to use this kind module to > repair/improve some old computers I have in storage.) > > /Andreas Andreas It is not on the web web yet. I will see if I can hurry it up. The power pins on Craignell are in the traditional DIL positions i.e. top right for 5V and bottom left for gnd as you look down on top. One word of warning - we had a big uptake of the Craignell modules and stocks have gone. Lead time maybe currently 4-6 weeks. We trying to improve that but our assembly line is very busy. Basically we under estimated demand but once this initial shortage is sorted I expect these modules to be a stock item. John Adair Enterpoint Ltd.Article: 119049
Hallo, do you know a way to perform gain and offset correction of the adc output in vhdl? Many Thanks Marco T.
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