In system memory editor of Altera for Xilinx

On Feb 1, 10:26=A0am, Goran_Bilski <goran.bil...@xilinx.com> wrote:
> On Feb 1, 7:36=A0am, rickman <gnu...@gmail.com> wrote:
>
>
>
>
>
> > On Jan 29, 12:06=A0pm, "jmunir" <jmunir@n_o_s_p_a_m.gts.tsc.uvigo.es>
> > wrote:
>
> > > So, my question is:
>
> > > When I implement a block and I would like to control several of his
> > > parameters to test its behaviour, do I have to recompile each time I =
want
> > > to change one of them? :O
>
> > > That has not sense! It is impractical!
>
> > > J.
>
> > I don't think you need to recompile the HDL. =A0You need to produce a
> > new bit stream from the original bitstream. =A0Still, this requires a
> > number of steps, which can be done in one step with a JTAG tool.
>
> > Rick
>
> Hi,
>
> If you have a design where you want to modify the BRAM contents,
> data2mem is the tool to use.
> It can modify an existing bitfile and creates a new bitfile with the
> new BRAM contents.
> After you have created the .bmm file, it's just one call to data2mem
> to create a new bitfile with modified BRAM contents.
> It takes a few seconds to finish.
>
> If you just want to toggle some registers down in the target, you can
> use Chipscope VIO which allows you to modify signal values in target
> using JTAG.
>
> I agree that it would be good to have a tool that allow you full
> control of everything in the device over JTAG but I can also think of
> 10+ other tools that would be good to have.
> Xilinx doesn't have an infinite number of resources for doing tools
> and we have to pick which one we should do.
>
> One can argue that a comprehensive JTAG debug tool should be one of
> them but as today, Xilinx has data2mem and chipscope.
> It allows customers accomplish what they want although it might not be
> in easiest way for everyone.
>
> G=F6ran

G=F6ran,

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

On Feb 1, 9:43=A0am, Antti <antti.luk...@googlemail.com> wrote:
> On Feb 1, 10:26=A0am, Goran_Bilski <goran.bil...@xilinx.com> wrote:
>
>
>
>
>
> > On Feb 1, 7:36=A0am, rickman <gnu...@gmail.com> wrote:
>
> > > On Jan 29, 12:06=A0pm, "jmunir" <jmunir@n_o_s_p_a_m.gts.tsc.uvigo.es>
> > > wrote:
>
> > > > So, my question is:
>
> > > > When I implement a block and I would like to control several of his
> > > > parameters to test its behaviour, do I have to recompile each time =
I want
> > > > to change one of them? :O
>
> > > > That has not sense! It is impractical!
>
> > > > J.
>
> > > I don't think you need to recompile the HDL. =A0You need to produce a
> > > new bit stream from the original bitstream. =A0Still, this requires a
> > > number of steps, which can be done in one step with a JTAG tool.
>
> > > Rick
>
> > Hi,
>
> > If you have a design where you want to modify the BRAM contents,
> > data2mem is the tool to use.
> > It can modify an existing bitfile and creates a new bitfile with the
> > new BRAM contents.
> > After you have created the .bmm file, it's just one call to data2mem
> > to create a new bitfile with modified BRAM contents.
> > It takes a few seconds to finish.
>
> > If you just want to toggle some registers down in the target, you can
> > use Chipscope VIO which allows you to modify signal values in target
> > using JTAG.
>
> > I agree that it would be good to have a tool that allow you full
> > control of everything in the device over JTAG but I can also think of
> > 10+ other tools that would be good to have.
> > Xilinx doesn't have an infinite number of resources for doing tools
> > and we have to pick which one we should do.
>
> > One can argue that a comprehensive JTAG debug tool should be one of
> > them but as today, Xilinx has data2mem and chipscope.
> > It allows customers accomplish what they want although it might not be
> > in easiest way for everyone.
>
> > G=F6ran
>
> G=F6ran,
>
> 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- Hide quoted text -
>
> - Show quoted text -

Hi Antti,

Every company has limited resources so this is not just Xilinx-
specific.

For this "godly" JTAG debug tool, I doubt that the USB JTAG cable API
is the main issue.
The tool would need to understand the complete configuration
description of every Xilinx architecture and device.
The tool also need to support all download cables and not just USB.

If this is not about the "godly" JTAG tool but rather that you want to
have access to the USB JTAG cable API, I can check if we plan to make
it public.
I think there is a generic cable API (which should cover all types of
download cables, not just USB) but I don't know the status of it.

G=F6ran

On Feb 1, 11:16=A0am, Goran_Bilski <goran.bil...@xilinx.com> wrote:
> On Feb 1, 9:43=A0am, Antti <antti.luk...@googlemail.com> wrote:
>
>
>
>
>
> > On Feb 1, 10:26=A0am, Goran_Bilski <goran.bil...@xilinx.com> wrote:
>
> > > On Feb 1, 7:36=A0am, rickman <gnu...@gmail.com> wrote:
>
> > > > On Jan 29, 12:06=A0pm, "jmunir" <jmunir@n_o_s_p_a_m.gts.tsc.uvigo.e=
s>
> > > > wrote:
>
> > > > > So, my question is:
>
> > > > > When I implement a block and I would like to control several of h=
is
> > > > > parameters to test its behaviour, do I have to recompile each tim=
e I want
> > > > > to change one of them? :O
>
> > > > > That has not sense! It is impractical!
>
> > > > > J.
>
> > > > I don't think you need to recompile the HDL. =A0You need to produce=
 a
> > > > new bit stream from the original bitstream. =A0Still, this requires=
 a
> > > > number of steps, which can be done in one step with a JTAG tool.
>
> > > > Rick
>
> > > Hi,
>
> > > If you have a design where you want to modify the BRAM contents,
> > > data2mem is the tool to use.
> > > It can modify an existing bitfile and creates a new bitfile with the
> > > new BRAM contents.
> > > After you have created the .bmm file, it's just one call to data2mem
> > > to create a new bitfile with modified BRAM contents.
> > > It takes a few seconds to finish.
>
> > > If you just want to toggle some registers down in the target, you can
> > > use Chipscope VIO which allows you to modify signal values in target
> > > using JTAG.
>
> > > I agree that it would be good to have a tool that allow you full
> > > control of everything in the device over JTAG but I can also think of
> > > 10+ other tools that would be good to have.
> > > Xilinx doesn't have an infinite number of resources for doing tools
> > > and we have to pick which one we should do.
>
> > > One can argue that a comprehensive JTAG debug tool should be one of
> > > them but as today, Xilinx has data2mem and chipscope.
> > > It allows customers accomplish what they want although it might not b=
e
> > > in easiest way for everyone.
>
> > > G=F6ran
>
> > G=F6ran,
>
> > 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- Hide quoted text -
>
> > - Show quoted text -
>
> Hi Antti,
>
> Every company has limited resources so this is not just Xilinx-
> specific.
>
> For this "godly" JTAG debug tool, I doubt that the USB JTAG cable API
> is the main issue.
> The tool would need to understand the complete configuration
> description of every Xilinx architecture and device.
> The tool also need to support all download cables and not just USB.
>
> If this is not about the "godly" JTAG tool but rather that you want to
> have access to the USB JTAG cable API, I can check if we plan to make
> it public.
> I think there is a generic cable API (which should cover all types of
> download cables, not just USB) but I don't know the status of it.
>
> G=F6ran

Xilinx has obsoleted the Parallel port cables, (no longer supported!)
so the USB cable is the only cable supported by official tools.

right publishing the API, would not "do it all" but it would open
possibility for more USEABLE and USEFUL tools to be developed
and offered for the Xilinx users.

Antti

Goran_Bilski <goran.bilski@xilinx.com> writes:

> I think there is a generic cable API (which should cover all types of
> download cables, not just USB) but I don't know the status of it.

What is the URL of this document?


Petter
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

On Feb 1, 7:48=A0pm, Petter Gustad <newsmailco...@gustad.com> wrote:
> Goran_Bilski <goran.bil...@xilinx.com> writes:
> > I think there is a generic cable API (which should cover all types of
> > download cables, not just USB) but I don't know the status of it.
>
> What is the URL of this document?
>
> Petter
> --
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on usenet and in e-mail?

C:\

its internal Xilinx document.

let's pray and hope it eventually comes public in some form

Antti

> 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.

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@netfront.net ---

On Jan 29, 7:30 pm, General Schvantzkoph <schvantzk...@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.

On Jan 29, 7:11 pm, Antti <antti.luk...@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?

On Feb 2, 1:41=A0am, Michael S <already5cho...@yahoo.com> wrote:
> On Jan 29, 7:11 pm, Antti <antti.luk...@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