In system memory editor of Altera for Xilinx
in [FPGA]
|
Prev: Thank you, SunMicrosystem
Next: CfP: 9th International Conference on Evolvable Systems (ICES2010)
From: General Schvantzkoph on 1 Feb 2010 13:09 > if-when Xilinx admits it has limited resources, then WHY Xilinx does not > allow 3rd party developer to help Xilinx customers? > > just a small decision to make: open up Xilinx USB Cable API, that is all > that Xilinx would have todo. Yes, this also takes resources as it may > require some maintenance and code cleanup from Xilinx, but if Xilinx > would do that cleanup, it may also be of benefit of Xilinx internal > developer team, so at the end Xilinx may actually win saving time not > spending it. > > I would love to re-think and re publish some of my old JTAG tools, but > without the ability to talk to Xilinx official USB cables it makes > little sense. > > Altera USB cables are EASY to talk, and there exist 3rd party software > that uses them. There is very little 3rd party software supporting > completly and without problems Xilinx USB cables. > > Antti Ideally both Xilinx and Altera should open source their ChipScope and SignalTap tools as well as the USB drivers. The Linux drivers for both companies are pretty terrible, if they were GPLed they could be incorporated into the Linux kernel which would make live a lot easier for both their customers and them. The only XP system that I maintain is an old machine that I use for SignalTap and Chipscope. When I tried to use SignalTap on CentOS5.4 on the same box it was unable to find the device about 95% of the time. Last year I had similar problems at a customer site using Chipscope on CentOS. If ChipScope and SignalTap worked reliably on Linux I'd dump the XP partition in a heartbeat. I don't think the debug tools are the family jewels for either company, buying decisions are made based on the devices. The synthesis and place and route tools have a huge impact on the performance of the parts so those clearly have to be closed source. But ChipScope and SignalTap only effect the performance of the users. If they were open sourced I'd bet their deficiencies would be fixed pretty quickly.
From: Alex Freed on 1 Feb 2010 17:30 Goran_Bilski wrote: > > If you have a design where you want to modify the BRAM contents, > data2mem is the tool to use. Yes, to some extent. Especially if the whole chunk of memory you are interested in lives in a single BRAM. If it is spread over several BRAMS things become a lot uglier. And as others mentioned it is very useful to bee able to peek inside the BRAM and change contents without a full cycle. When debugging simple soft CPU cores nothing beats Altera's memory editor. As for the cable I think it was really stupid to close the design. Yes, they could sell for $300 a box that costs $20 to make but this extra revenue is probably a lot less than losses from bad publicity. And now ebay is full of reverse engineered USB cables from China anyway. -Alex. --- news://freenews.netfront.net/ - complaints: news(a)netfront.net ---
From: Michael S on 1 Feb 2010 18:35 On Jan 29, 7:30 pm, General Schvantzkoph <schvantzk...(a)yahoo.com> wrote: > On Fri, 29 Jan 2010 08:13:56 -0800, austin wrote: >Just to be even handed about > this, the Altera people would benefit from looking at Xilinx's method of > doing timing analysis. Altera introduced a new timing tool a couple of > years ago and it still sucks. Xilinx produces an easy to read timing > report that you can look at in Emacs. It shows the fanout and delays of > each stage of the worst case paths, formatted as one line per level. > Xilinx also figures out derivative clocks automatically, all you have to > do is specify the reference clock speed and the tools automatically > figures out the rates and phase relationships of all of the outputs of > the PLL or DCM. The Altera tools forces you to do that by hand, what's > worse is that you can't even do it using the clock names, you have to > figure out the path to the output port of the PLL. Add the following couple of lines to your .sdc derive_pll_clocks derive_clock_uncertainty They would cover 99% of the cases you described above Timequest timing analyzer still sucks in some important aspects (e.g. support for reference pin in delay specifications inconsistent, output skew constrains don't work at all), but that particular part mostly works > Altera's report format > is utterly unusable, you are forced to look at worst case paths in the > GUI and what it puts out is nearly unreasonable. That's true. Timequest Analizer/Timequest Analizer GUI dichotomy makes absolutely no sense. And report formats are hard to follow in the text editor. > The bottom line is that > I do all of my timing closure using Xilinx tools even if the design is > targeted at an Altera part. Once the Xilinx version meets timing I run it > through Quartus and hope that I only have a couple of paths that need > fixing. Well, that's certainly sounds too extreme.
From: Michael S on 1 Feb 2010 18:41 On Jan 29, 7:11 pm, Antti <antti.luk...(a)googlemail.com> wrote: > > but.. DATA2MEM is MUCH more important (yeah for the customers) then > the memory editor > and well Altera has no data2mem possibility at all, what is real > problem. > What exactly data2mem can do, but quartus_cdb+quartus_asm can't? Except, of course, that quartus_cdb needs a whole db directory, which, at least for me, doesn't sound like a serious obstacle. Or do you feel that quartus_cdb is too high level?
From: Antti on 1 Feb 2010 19:02
On Feb 2, 1:41 am, Michael S <already5cho...(a)yahoo.com> wrote: > On Jan 29, 7:11 pm, Antti <antti.luk...(a)googlemail.com> wrote: > > > > > but.. DATA2MEM is MUCH more important (yeah for the customers) then > > the memory editor > > and well Altera has no data2mem possibility at all, what is real > > problem. > > What exactly data2mem can do, but quartus_cdb+quartus_asm can't? > Except, of course, that quartus_cdb needs a whole db directory, which, > at least for me, doesn't sound like a serious obstacle. > Or do you feel that quartus_cdb is too high level? data2mem is standalone tool that doesnt need ANY design files except final BIT file and .text BMM file. any tool flows that use DESIGN intermediate files (Altera and Lattice flow) are not OK. if a company is serious about soft-core processor than that company should offer data2mem type of functionality. too PITA Altera does not listen. Antti |