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
Viktor Steinlin wrote: > Hello, > I'm about to design a frame grabber where I need high memory bandwidth. > Does anybody has already implemented a design with Xilinx Virtex-II PRO and > DDR2 SDRAM. Have you encountered major problems with DDR2 controller > provided by Xilinx EDK? Some design hints? OK, I'm stupid: Where is this DDR2 SDRAM-controller you are talking about? It's not included in my EDK6.3... is this an add-on-option you bought from Xilinx separately? I face the same decision (DDR1 vs. DDR2) at the moment... I do not believe, however, that DDR1 will disappear anytime soon... new computers shipped will have DDR2, but you can still buy SDR-SDRAM and even old PS/2-SIMMs today, and these technologies haven't been used in PCs, a.k.a. "the mass market", for quite awhile... cu, SeanArticle: 76651
I assume you have gated clock because you want to suspend the operation of some sequential logics when you want it. If that's what you want, instead of having gated clock, you can have "clock enable". The following example explains what I mean by "clock enable" Let's say you want to have a 4 bit counter, but you want to stop the counter from counting when you want it. You can do it this way always @(posedge clk) begin if (clock_enable) counter <= counter + 1; else counter <= counter; end This way, your counter is completely synchronous and still having the ability to make the counter to stop counting by driving clock_enable to low. The same technique can be used to slow down your sequential logics, without having to have multiple clocks in your design. For example: Let's say you want to have 2 seperate DFFs, one runs at 50 MHz and the other runs at 100 MHz. Instead of having two different clocks in your system, you can just have one clock, runs at 100 MHz. reg [1:0]clock_divide; always @(posedge clk) begin clock_divide <= clock_divide + 1; end //DFF 1 always @(posedge clk) begin if (clock_enable[1]) q1 <= d1; else q1 <= q1; end //DFF 2 always @(posedge clk) begin q2 <= d2; end This way, your DFF2 runs at 100 MHz, while your DFF1 runs at 50 MHz. Both DFFs run at different frequencies, without having to have 2 different clocks. HendraArticle: 76652
CORRECTION: The second example should be: reg [1:0]clock_enable; always @(posedge clk) begin clock_enable <= clock_enable + 1; endArticle: 76653
Hi Paul, Comments/Questions below! "Paul Leventis (at home)" <paulleventis-news@yahoo.ca> wrote in message news:686dnTKPrvwyGyvcRVn-pQ@rogers.com... > (2) LUT Configuration. A LUT configured as an AND gate does not burn > nearly > as much power as one configured as an XOR. This difference is due to the > number of internal nodes in the circuit that toggle states upon the toggle > of in input signal. On top of this, (blah, blah, XORs transition more) Could you explain that a little more? I thought that the LUT was just a 16x1 RAM. Is the extra power consumed only when two inputs change? e.g. 00 => 11 into the XOR would still have 0 as its output but it might transistion through the 1 output state? I understand that XOR gates are more likely to transition, but you seem to be saying there's some additional internal reason why they consume power. > > Paul Leventis > Altera Corp. > Cheers, Syms.Article: 76654
On 7 Dec 2004 22:11:40 -0800, "Harish" <harish.vutukuru@gmail.com> wrote: >How about dual port BRAM? My understanding is that both the ports have >access to the same BRAM. So if in through one port you want to read the >data and through the other port you want to write the data to same >memory location what will happen? > >Thanks This is called "you get what you deserve" mode. This is explaind in detail here: http://www.fpga-faq.com/archives/72650.html#72651 Philip Freidin =================== Philip Freidin philip.freidin@fpga-faq.com Host for WWW.FPGA-FAQ.COMArticle: 76655
"Chandrasekhar" <chandu_419@yahoo.com> wrote in message news:1102489026.603341.150020@c13g2000cwb.googlegroups.com... > Hi All, > > I m facing some problems with clock gating in Virtex II FPGA > using BUFGMUX, The Xilinx ISE 6.2.03i is saying the design is not > completely routable. I know that clock gating in an FPGA is not > advisable, but my requirement is like that. No it isn't. Use enables instead. The tool has saved you from months of pain by refusing to connect up such an abomination! > I have total 15 clocks of 5 > diffterent frequencies. All these 15 clocks are gated with gate enable > before going to the individual modules. The gating must be done in my > clock tree module only. > > Can anyone please give some inputs on this... Any help will > be greatly appreciated. > > Thanks... > Chandrasekhar. > Fix it so you have one clock. Make it faster than the others; why not use a DCM to create it? Use enables for your original 15 clocks. If necessary, retime the stuff from the various clock domains on the way in, and on the way out, in your 'clock tree module'. A little thought up front will save you so many problems. Here's a resynchronising circuit posted by Rick Collins to get you going. http://www.fpga-faq.com/archives/59400.html#59400 Good luck, Syms.Article: 76656
On Tue, 07 Dec 2004 16:13:13 +1100, Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote: >>> Ten highest spurious tones: >>> >>> 55.000kHz -11.4dBc >>> 367.000kHz -16.7dBc >>> 101.000kHz -17.0dBc >>> 165.000kHz -22.4dBc >>> 9.000kHz -22.9dBc >>> 257.000kHz -24.1dBc >>> 321.000kHz -25.1dBc >>> 147.000kHz -25.8dBc >>> 119.000kHz -27.4dBc >>> 37.000kHz -27.7dBc Sorry, The frequencies are right, but I messed up the amplitudes. I realised the mistake when I checked by FFT-ing the output of a phase accumulator (using Excel!). This is closer to reality: 367.000kHz -9.5dBc 55.000kHz -14.0dBc 477.000kHz -16.9dBc 101.000kHz -19.1dBc 321.000kHz -20.8dBc 257.000kHz -22.3dBc 165.000kHz -23.5dBc 413.000kHz -24.6dBc 9.000kHz -25.6dBc etc. I've only considered the spurious tones between 0Hz and 500kHz. Each of these tones will have an alias between 1MHz and 500kHz. Note that the relative amplitudes of the highest spurious tones follow a 1/3, 1/5, 1/7, 1/9 ... sequence. Regards, AllanArticle: 76657
In dp_block_mem.pdf, it states: The Spartan-II/Virtex and Virtex-II/Spartan-3 block memory is True Dual-Port RAM that allows both ports to simultaneously access the same memory location. When one port writes to a given memory location, the other port must not address that memory location (for a write/read) within the clock-to-clock setup window. Note that conflicts do not cause any physical damage to BlockRAM cells. For more information on conflict resolution, refer to the Spartan-II, VIrtex, Virtex-II/Spartan-3 Databook available at the website: http://www.xilinx.com/partinfo/databook.htm In coregen, after one selects the particular IP, there is a "Data Sheet" button that links information about the IP block. The above was taken directly from the "Data Sheet" - Newman "Harish" <harish.vutukuru@gmail.com> wrote in message news:1102486300.214476.266890@c13g2000cwb.googlegroups.com... > How about dual port BRAM? My understanding is that both the ports have > access to the same BRAM. So if in through one port you want to read the > data and through the other port you want to write the data to same > memory location what will happen? > > > Thanks >Article: 76658
I need an information about some prices for some fpga. Acex1k speed -1, 208 pins. Cyclone speed -6, 240pins. Thanks,Article: 76659
Hi, I have written a little .do-script with which the VHDL files are compiled and the simulation is performed. When I open Modelsim I have to go to FILE --> CHANGE DIRECTORY and then I have to enter the path of my simulation directory including my script. How can I do this directory changing automatically at the beginning of my script ? Is there any command ? I would appreciate your help. Here is the script vlib work # Compile base libraries vcom util1164.vhd vcom stdlogar.vhd vcom io_utils.vhd vcom mti_pkg.vhd # Compile test vectors vcom vec_gen.vhd vcom ed_comnd.vhd vcom -93 ../../../sdram_ctrl/sdram_positions_arbitration/ fraction_sdram_numbers_fifo.vhd vcom -93 ../../../sdram_ctrl/sdram_positions_arbitration/ mux_fraction_fifo_outputs.vhd vcom -93 ../../../sdram_ctrl/sdram_positions_arbitration/sdram_pos_arbiter.vhd vcom -93 ../../../sdram_ctrl/sdram_positions_arbitration/ sdram_positions_arbitration.vhd vcom -93 ../../../sdram_ctrl/valid_bytes_in_row.vhd vcom -93 ../../../sdram_ctrl/tristate_buffer.vhd vcom -93 ../../../sdram_ctrl/sdram_controller.vhd vcom -93 ../../../sdram_ctrl/sdram_ctrl.vhd vcom -93 ./mt48lc8m16a2.vhd vcom -93 ../../../sie_trans_fs/read_burst_fifo.vhd vcom -93 ../../../sie_trans_fs/crc16_8bit_in.vhd vcom -93 ../../../sie_trans_fs/sie_trans_fs.vhd vcom -93 ./tb_sdram_ctrl_sie_fs.vhd vsim tb_sdram_ctrl_sie_fs do Simulationsplot_sdram_ctrl_sie_fs.do run 1200us -all configure wave -signalnamewidth 1 set StdArithNoWarnings 1 set IgnoreWarning 1 set DefaultRadix unsignedArticle: 76660
You can use an identifier to have a fully parametric script, so that you can get rid of physical location of your HDL codes. Example: ---- do script ---- ... set designlib /home/AluPin/sdram_chip ... vcom -93 $designlib/sdram_ctrl/sdram_positions_arbitration/sdram_pos_arbiter.vhd ... --- end of script --- You can further parametrize your RTL simulation environment by placing "$designlib" into a separate *.do script. This way you can move the complete design directory to another location. In this case you just need to update the *.do script called in your script: --- do script --- ... do chip_global.do <-- designlib is defined here!! ... vcom -93 .... ... --- end of script --- In "chip_global.do": --- ... set designlib /home/AluPin/sdram_chip ... --- ... and other necessary variables go there. Utku ALuPin wrote: > > Hi, > > I have written a little .do-script with which > the VHDL files are compiled and the simulation is performed. > > When I open Modelsim I have to go to > FILE --> CHANGE DIRECTORY and then I have to enter > the path of my simulation directory including my script. > > How can I do this directory changing automatically at the beginning > of my script ? Is there any command ? > > I would appreciate your help. > > Here is the script > > vlib work > # Compile base libraries > vcom util1164.vhd > vcom stdlogar.vhd > vcom io_utils.vhd > vcom mti_pkg.vhd > # Compile test vectors > vcom vec_gen.vhd > vcom ed_comnd.vhd > > vcom -93 ../../../sdram_ctrl/sdram_positions_arbitration/ > fraction_sdram_numbers_fifo.vhd > vcom -93 ../../../sdram_ctrl/sdram_positions_arbitration/ > mux_fraction_fifo_outputs.vhd > vcom -93 ../../../sdram_ctrl/sdram_positions_arbitration/sdram_pos_arbiter.vhd > vcom -93 ../../../sdram_ctrl/sdram_positions_arbitration/ > sdram_positions_arbitration.vhd > > vcom -93 ../../../sdram_ctrl/valid_bytes_in_row.vhd > vcom -93 ../../../sdram_ctrl/tristate_buffer.vhd > vcom -93 ../../../sdram_ctrl/sdram_controller.vhd > vcom -93 ../../../sdram_ctrl/sdram_ctrl.vhd > vcom -93 ./mt48lc8m16a2.vhd > vcom -93 ../../../sie_trans_fs/read_burst_fifo.vhd > vcom -93 ../../../sie_trans_fs/crc16_8bit_in.vhd > vcom -93 ../../../sie_trans_fs/sie_trans_fs.vhd > > vcom -93 ./tb_sdram_ctrl_sie_fs.vhd > vsim tb_sdram_ctrl_sie_fs > do Simulationsplot_sdram_ctrl_sie_fs.do > run 1200us -all > > configure wave -signalnamewidth 1 > set StdArithNoWarnings 1 > set IgnoreWarning 1 > set DefaultRadix unsigned -- This is a SUNW,Ultra-80 machine. 3:15pm up 56 day(s), 3 min(s), 1 user, load average: 0.14, 0.13, 0.08Article: 76661
Dan wrote: > I need an information about some prices for some fpga. > > Acex1k speed -1, 208 pins. > Cyclone speed -6, 240pins. your distributor might be of help. Or try http://www.ebv.com Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 76662
The Acex I don't know but the Cyclone1 1C6 240 speed grade -8 I get for about $34. Victor http://www.zertec.co.za "Dan" <dan.costin@gmail.com> wrote in message news:f4e089e0.0412080410.5ce72807@posting.google.com... > I need an information about some prices for some fpga. > > Acex1k speed -1, 208 pins. > Cyclone speed -6, 240pins. > > Thanks,Article: 76663
hi, i solved that annoing problem modifing the modelsim.ini file that in my computer is placed into the directory: C:\Programs\Modeltech_xe\examples the line that i added (or changed... i do not remember) is the following: ######################### ; VSIM Startup command Startup = do wdir.do ######################### and the wdir.do file is placed in the same directory with the following command: ######################### cd e:/work/fs/sim ######################### hope this help andreaArticle: 76664
John_H wrote: > > I've tried to work this issue some in the past. Since you're using Xilinx, > the adders are vertical structures that occupy half a CLB allowing 2 adders > per CLB column. The final adder has two inputs that come from smaller adder > trees to the right and left for minimum propagation. I ended up going into > the FPGA Editor to try different configurations to come up with the > "optimum" delay. Most architectures like inputs that are one or two columns > away with a feedback within a column sometimes producing better, sometimes > worse delays compared to the adjacent column. > > Proper timing constraints would *ideally* give you the nice, right/left > distributed adders.where bits at the same level are in the same CLB row > across the adders. The P&R tool tends to be a little less precise but might > be coerced into giving proper results with better constraints than I've > developed. For the extremely tight designs I tend to RLOC the adders. It's > a pain in Verilog but I haven't had to RLOC more than one or two moderately > sized adder trees. > Thanks for this input. I certainly don't want to try to use FPGA editor to experiment with different configurations, so this is helpful. At one point I tried to put the whole tree in a single row like you suggest, but one problem with that is that the adder inputs come from BRAMs, which are in a long column. I guess I could register the BRAM outputs (a second time) to get all the signals to a single row, where the tree would lie. -KevinArticle: 76665
Hello Rick, Thanks for the reply. I hope Xilinx provides with the information as how they restrict the resources within the column. With regard to the other questions I do plan to write my own software working on the top of Xilinx tools( I am still analyzing the issues associated with it) Thanks HarishArticle: 76666
Ray Andraka wrote: > Well, if you must use a tree (more on that in a minute), then your best bet > is to include RLOCs for the adders. You get reasonable performance by > placing the first level in every other slice column and then placing the > next levels in every other vacant column until you reach the root. > "Reasonable" depends on the depth of the tree and your clock speed of > course. It starts losing performance at 3 levels or so, because of the > progressively longer routes. You can make up the speed by adding pipeline > registers at the cost of real-estate. > > In the case of an FIR filter, however, you don't need a tree. Instead, push > part or all of the tap delay through the coefficient multiplies so that you > can connect the adders in a linear array (ie daisy chained), absorbing the > delays into the adder registers. That gives you all nearest neighbor > connections, and if you do it right, the latency is actually less than a > tree. The cost is if you need to clock enable it, your control task is much > more complicated. > Your suggestion on tree layout is exactly what I was looking for. It seems my tree that is floorplanned like a tree isn't the best plan. You are right about the transpose FIR architecture, though. I have become convinced that that is the best choice because of the ease of layout. I will be able to place the adders right next to the BRAMs in the column and the datapaths will be nice and short. -KevinArticle: 76667
Hello, This is my first FPGA design and a pretty huge one. Well I believe :=) First of all, the target is imposed and is an APEX20KE, and I use Quartus. It is for an XY detectors array 128x128 and thus have 256 head cells, each one with its state machine. Each cell has to work in cooperation with its immediate neighbours in order to resolve some incoming events that can be spread over several consecutive cells. Each cell has a local time counter (100MHz) in order to have the cell's event duration. Now my problem : Several events may occur at the same time anywhere on the detector, but for simplicity lets consider just one physical event occurence, which translate to a group of several pulses occuring on a set of not disjoint cells (I call this a cluster). Now each cell compares its local time to a T1 value (fixed delay after the first incoming rising transition) and at the first T1 occurence in the cluster I have to sample all the cluster cells states (input active or not), **but only for the cells of this cluster** and this have to be done in preferably one, maybe two 100MHz clock cycles (we don't want adjacent clusters to compete for their boundaries). Wouldn't have been the two last conditions that would be almost straightforward, but this makes the exercise difficult. This almost reduces as : how do I propagate through a group of cells as fast as possible, while controling its propagation. I forgot to mention that the maximum allowed cluster size is 8 cells. Above, all the cluster is rejected and we have time to do this. So we "just" have to be fast on, at worst, 8 cells. As we don't want "boundary competition" I can't imagine a clocked process for the sampling signal propagation. I first thought of using the cascade or fast carry chains, but I've had no success. Another idea was to "ripple sample" the cells, i.e. tie each cell samplingFF clock to the previous cell samplingFF output, and having the D input allowing signal propagation. And after that I have 1 or two resync FFs. Unfortunately I have only 2 clocks available per LAB (10 LE) and this would take too much place. The best I could come with is (with my FPGA): - At the first occuring T1, I asynchronously propagate a cell sampling enable signal from one cell to the next, until I encounter a boundary cell. This is hoped to be fast enough to propagate through the max cluster size (8 consecutive cells) within the allowed time (10 or 20 ns). - then after the sampling period (10 or 20ns) all the allowed cells are sampled, and, hum, et voila. Unfortunatly, and quite obvioulsy, the fitter complains about a truck load of timing violations, since I have 127 chained LUTs to propagate and control the sampling signal from the first cell to the last one. All I want to do is ensure that the propagation time through a segment (max length = 8) is under control. How can I do that ? Any other idea about the design is also welcomed. -- Thanks, Fred.Article: 76668
Looks like ST Micro has been trying to unsuccessfully develop a new FPGA for many years with 100s of engineers. The good thing to come out of this project is that they are open-sourcing the EDA tools they developed for their FPGA. These tools (Synthesis, P&R etc) are available at: http://www.gospl.org Specifically, see: http://www.gospl.org/fpl/static/aboutgospl.jsp This is good for researchers to play around with tools. And at first glance, looks like a true open-source license (publish any changes to source code that you make). However, ST benefits the most, since they get free tool enhancement, while they sell their FPGA fabric as an embedded FPGA fabric. SumitArticle: 76669
SG wrote: > > Looks like ST Micro has been trying to unsuccessfully develop a new > FPGA for many years with 100s of engineers. The good thing to come > out of this project is that they are open-sourcing the EDA tools they > developed for their FPGA. These tools (Synthesis, P&R etc) are > available at: > http://www.gospl.org > > Specifically, see: > http://www.gospl.org/fpl/static/aboutgospl.jsp > > This is good for researchers to play around with tools. And at first > glance, looks like a true open-source license (publish any changes to > source code that you make). However, ST benefits the most, since they > get free tool enhancement, while they sell their FPGA fabric as an > embedded FPGA fabric. They may be able to create a viable business model using this approach, but it will require a *LOT* more than just open source tools. The key to their product acceptance is that it has to be a *GOOD* FPGA architecture. The fact that they don't say much about the hardware and the fact that it does not look like the hardware is open source says to me that the open source software won't be much of an advantage. Sure, they will get academia to work on their software for them. But much of that will be pie-in-the-sky stuff and likely the tools will not really be any better than the tools available for the mainstream vendors. Where do you find info about the FPGA? -- 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: 76670
"rickman" <spamgoeshere4@yahoo.com> wrote in message news:41B75023.9D218EC5@yahoo.com... > SG wrote: > > > > Looks like ST Micro has been trying to unsuccessfully develop a new > > FPGA for many years with 100s of engineers. The good thing to come > > out of this project is that they are open-sourcing the EDA tools they > > developed for their FPGA. These tools (Synthesis, P&R etc) are > > available at: > > http://www.gospl.org > > > > Specifically, see: > > http://www.gospl.org/fpl/static/aboutgospl.jsp > > > > This is good for researchers to play around with tools. And at first > > glance, looks like a true open-source license (publish any changes to > > source code that you make). However, ST benefits the most, since they > > get free tool enhancement, while they sell their FPGA fabric as an > > embedded FPGA fabric. > > They may be able to create a viable business model using this approach, > but it will require a *LOT* more than just open source tools. The key > to their product acceptance is that it has to be a *GOOD* FPGA > architecture. The fact that they don't say much about the hardware and > the fact that it does not look like the hardware is open source says to > me that the open source software won't be much of an advantage. Sure, > they will get academia to work on their software for them. But much of > that will be pie-in-the-sky stuff and likely the tools will not really > be any better than the tools available for the mainstream vendors. > > Where do you find info about the FPGA? there is some small diagram of the arch, but not more :( sure there is more needed than just the tools, but the FPGA arch doesnt need to be *GOOD* (eg very good) - its not possible to be good for every application anyway. If the FPGA Arch is "useable" at least then there could be some market already. Plessey had ERA6K ram-based sea-of-gates array in the "early days" - that product died (in my opinion) mostly because the software company Pilkington never deliver the tools for the ERA6K. (Well just recently I heard that there where some problems inside Plessey at time too). Anyway I still belive that if superior tools would have been available for ERA6K it would not have died or would have merged into some better product. Whatever arch the GOSPL is targetting, I am pretty sure it is useable - specially when implemented in the modern technology. If somebody would care to calc how much time have people wasted fighting with FPGA tools from "mainstream vendors" ? Then take that hour(days months years) count and multiply with some reasonable $$ pay/per hour? The number would be huge! But there is no way around, the tools are still bad (sure improving all the time sure), and the tool updates/service packs, ipcore versions, SoC system builder update incompatibilities, those all take huge amount of time from all of us. Could that time be saved? If and only if there would a full toolchain that really works: you write the RTL, you write the C code, select the softcore-cpu + peripherals: the SoC's is built, the ip cores are integrated, the bitstream is built from single keypress (after design change) - if that would really work, then well even if it only targets a not so advance FPGA arch, there would be interest and market for it. AnttiArticle: 76671
Antti Lukats wrote: > > sure there is more needed than just the tools, but the FPGA arch doesnt need > to be *GOOD* (eg very good) - its not possible to be good for every > application anyway. If the FPGA Arch is "useable" at least then there could > be some market already. That is what I disagree with. There is an established market with established market leaders. Rather like many industries, like the auto industry, unless you can provide a superior product, you don't have much chance of gaining market share against the established leaders. > Plessey had ERA6K ram-based sea-of-gates array in > the "early days" - that product died (in my opinion) mostly because the > software company Pilkington never deliver the tools for the ERA6K. (Well > just recently I heard that there where some problems inside Plessey at time > too). Anyway I still belive that if superior tools would have been available > for ERA6K it would not have died or would have merged into some better > product. They are not the only company to try to enter the mature FPGA market. Motorola had an architecture that was supported by the Neocad tools. But even before they sold a single chip, they realized that bringing a new FPGA to market was a *HUGE* undertaking. It would be easier to bring out yet another CPU architecture (which Motorola has done many time). So they cancled the FPGA before it even met the market. > Whatever arch the GOSPL is targetting, I am pretty sure it is useable - > specially when implemented in the modern technology. Useable is not the same as marketable. Engineers just want something they can get the job done with. Currently the tools are not a significant impediment. If the tools provided some advantage, like time to market, then they might have a chance. But it will be a long time before the open source tools are *superior* the the current vendor supplied tools. I believe this is why ST is targeting "embedded" FPGA structures. This is still a new market and much more open to a new vendor. > If somebody would care to calc how much time have people wasted fighting > with FPGA tools from "mainstream vendors" ? Then take that hour(days months > years) count and multiply with some reasonable $$ pay/per hour? The number > would be huge! But there is no way around, the tools are still bad (sure > improving all the time sure), and the tool updates/service packs, ipcore > versions, SoC system builder update incompatibilities, those all take huge > amount of time from all of us. Could that time be saved? No open source tool will be much better in those areas as has been discussed here many times. Unlike software tools, FPGA tools have to evolve much more quickly to adapt to the changes in FPGAs and FPGA markets. This results in lots of updates and lots of bugs. (BTW Mentor, are you *ever* going to fix the bug where Modelsim crashes randomly for no special reason???) I dont' see open source tools fixing any of this. The current open source front end tools are still far inferior to vendor supplied tools. > If and only if there would a full toolchain that really works: you write the > RTL, you write the C code, select the softcore-cpu + peripherals: the SoC's > is built, the ip cores are integrated, the bitstream is built from single > keypress (after design change) - if that would really work, then well even > if it only targets a not so advance FPGA arch, there would be interest and > market for it. Not before I retire.... but hey, "build it and they will come". -- 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: 76672
The key things here is that ST Micro is going after the embedded FPGA market. This is not an established market and Xilinx & Altera will have advantages only in terms of tool familiarity. About ST's architecture, if the Logic synthesis and P&R tools are open source, it should be very easy to figure out what the architecture is. Also, I don't think its a very big innovation, otherwise, ST would go after the standalone FPGA market, instead of a non-existant embedded FPGA market. My 2 cents. SumitArticle: 76673
rickman <spamgoeshere4@yahoo.com> wrote: > No open source tool will be much better in those areas as has been > discussed here many times. Unlike software tools, FPGA tools have to > evolve much more quickly to adapt to the changes in FPGAs and FPGA > markets. This results in lots of updates and lots of bugs. Perhaps, but the point remains that quite a lot of people would be happy with not-so-bleeding-edge FPGAs and a more accessible toolset than brand X or A offer. So, if you already have not-so-bleeding-edge FPGAs, open sourcing your toolset is one way of meeting that demand. And potentially a very effective way: if you play it right, you can get a lot of help from the open-source community. > (BTW > Mentor, are you *ever* going to fix the bug where Modelsim crashes > randomly for no special reason???) I dont' see open source tools fixing > any of this. The current open source front end tools are still far > inferior to vendor supplied tools. I had to laugh when I saw that combination of sentences. The whole open source movement was started by people that got frustrated with software vendors that ignored bug reports. And it does help. > > If and only if there would a full toolchain that really works: you write the > > RTL, you write the C code, select the softcore-cpu + peripherals: the SoC's > > is built, the ip cores are integrated, the bitstream is built from single > > keypress (after design change) - if that would really work, then well even > > if it only targets a not so advance FPGA arch, there would be interest and > > market for it. > > Not before I retire.... but hey, "build it and they will come". Personally, I believe this is possible, but the problem is always that the stuff on offer has to be right. A vendor with a weak FPGA and a rotten toolset will get nowhere. A vendor with a good FPGA and a good toolchain may well have a smash hit. But I think the key phrase in this business plan is KEEP IT SIMPLE.Article: 76674
"John_H" <johnhandwork@mail.com> schrieb im Newsbeitrag news:S9std.14$a61.1075@news-west.eli.net... > All this assumes, of course, that there's an analog PLL driven by the single > bit, noise-shaped NCO output. Without the PLL to filter out the high > frequency phase noise of a Sigma-Delta style NCO, the jitter is still around > 1 reference clock period peak-to-peak, maybe worse. Yes. > (NCOs are used by many folks in the comp.arch.fpga newsgroup who have no > reason to visit comp.dsp.) ???? Dont get it. Regards Falk
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