+++ David Brownell [2009-10-29 12:37 -0700]:
> On Thursday 29 October 2009, Wookey wrote:
> >
> > Cheers very much for that. Now to see if the 'only works on amd64' and
> > 'only works every other time' bugs from r1613 have gone in latest :-)
>
> I was curious about that. Could that XScale stack
On Thursday 29 October 2009, Wookey wrote:
>
> > CUT HERE
> > Preliminary implementation of XSVF support for detailed
> > state path transitions.
>
> Well, my part in that was much easier than I expected, and you sir,
> are a genius :-)
I wouldn't go that far ... but feel free to fe
+++ David Brownell [2009-10-27 19:17 -0700]:
> On Tuesday 27 October 2009, Wookey wrote:
> > > So if I whack together a patch turning XSVF's (c) into
> > > the (b) which is supported, you could test it and maybe
> > > fix any goofs?
> >
> > Yes, I think so (fighting chance at least).
>
> Alrighty
On Tuesday 27 October 2009, Wookey wrote:
> > So if I whack together a patch turning XSVF's (c) into
> > the (b) which is supported, you could test it and maybe
> > fix any goofs?
>
> Yes, I think so (fighting chance at least).
Alrighty ...
CUT HERE
Preliminary implementation of XSV
+++ David Brownell [2009-10-27 11:30 -0700]:
> On Tuesday 27 October 2009, Wookey wrote:
> > > Does that SVF version work OK?
> >
> > No, but then I wouldn't expect it to in this case. The xsvf command
> > allows the specification of a tap which means that an XSVF file
> > nominally created for a
On Tuesday 27 October 2009, Wookey wrote:
> > Does that SVF version work OK?
>
> No, but then I wouldn't expect it to in this case. The xsvf command
> allows the specification of a tap which means that an XSVF file
> nominally created for a single JTAG port still works with chained
> ports (magica
+++ David Brownell [2009-10-26 12:02 -0700]:
> On Monday 26 October 2009, Wookey wrote:
> > OK. results of today's testing on 0.3.0-dev-00427-g8b30f22
> > (2009-10-26-13:18)
> >
> > ...
> >
> > I get
> > xsvf processing file: "vhdl/cpld/l3cpld.xsvf"
> > Error: XSVF: 'XSTATE IREXIT2' ... NYET
> >
On Monday 26 October 2009, Wookey wrote:
> OK. results of today's testing on 0.3.0-dev-00427-g8b30f22 (2009-10-26-13:18)
>
> ...
>
> I get
> xsvf processing file: "vhdl/cpld/l3cpld.xsvf"
> Error: XSVF: 'XSTATE IREXIT2' ... NYET
> unsupported xsvf command (0x00) at offset 48, aborting
> Runtime err
+++ David Brownell [2009-10-21 09:49 -0700]:
> On Wednesday 21 October 2009, Wookey wrote:
> > > I'm going to commit this even though I can't test it.
> >
> > I'll test this imminently. SVF/XSVF has been completely broken since
> > r1614 when the set of permitted transitions was reduced to be 'mor
On Wednesday 21 October 2009, Zach Welch wrote:
> I need to climb the SVF/XSVF learning curve, so I am not sure about how
> to contribute to this myself Any ideas for how to go about it?
Start with the Wikipedia SVF page, which include refs
to the specs. To a first approximation, XSVF is jus
On Wed, 2009-10-21 at 22:43 +0100, Wookey wrote:
> +++ David Brownell [2009-10-21 10:05 -0700]:
> > On Wednesday 21 October 2009, Wookey wrote:
> > >I recently tried using
> > > the python (3.0!) converter which allegedly converts 'illegal' xilinx
> > > xsvf files into kosher xsvf files, but I
+++ David Brownell [2009-10-21 10:05 -0700]:
> On Wednesday 21 October 2009, Wookey wrote:
> > I recently tried using
> > the python (3.0!) converter which allegedly converts 'illegal' xilinx
> > xsvf files into kosher xsvf files, but I still found that all I got
> > was 'illegal transition' e
On Wednesday 21 October 2009, Wookey wrote:
>I recently tried using
> the python (3.0!) converter which allegedly converts 'illegal' xilinx
> xsvf files into kosher xsvf files, but I still found that all I got
> was 'illegal transition' errors, just a few lines later than without
> that tra
On Wednesday 21 October 2009, Wookey wrote:
> > I'm going to commit this even though I can't test it.
>
> I'll test this imminently. SVF/XSVF has been completely broken since
> r1614 when the set of permitted transitions was reduced to be 'more
> compliant'.
I kind of got the impression that it
+++ David Brownell [2009-10-20 19:58 -0700]:
> On Tuesday 20 October 2009, David Brownell wrote:
> > This layers parts of XSVF directly over SVF, to handle XSTATE better,
> > instead of expecting jtag_add_pathmove() to conform (it doesn't).
Thanx for working on this.
> I'm going to commit this ev
On Wed, Oct 21, 2009 at 4:58 AM, David Brownell wrote:
> On Tuesday 20 October 2009, David Brownell wrote:
>> This layers parts of XSVF directly over SVF, to handle XSTATE better,
>> instead of expecting jtag_add_pathmove() to conform (it doesn't).
>
> I'm going to commit this even though I can't
On Tuesday 20 October 2009, David Brownell wrote:
> This layers parts of XSVF directly over SVF, to handle XSTATE better,
> instead of expecting jtag_add_pathmove() to conform (it doesn't).
I'm going to commit this even though I can't test it.
Since we *know* jtag_add_statemove() [TYPO ABOVE!] is
On Tuesday 20 October 2009, David Brownell wrote:
> This layers parts of XSVF directly over SVF, to handle XSTATE better,
> instead of expecting jtag_add_pathmove() to conform (it doesn't).
> It also removes related bogus comments about jtag_add_pathmove().
... and in fact I'm thinking that XSVF s
This layers parts of XSVF directly over SVF, to handle XSTATE better,
instead of expecting jtag_add_pathmove() to conform (it doesn't).
It also removes related bogus comments about jtag_add_pathmove().
There is one set of XSTATE cases that's not handled right yet: when
it's used to build some arb
19 matches
Mail list logo
