Re: [Xc3sprog-users] bscan 59a6 bug

[joosteto <joo...@gm...>]

Uwe Bonnes wrote:
> joosteto posted a possible cure, however I have not verified yet.
Applying the fix however will void all .bit files we have.

I actually proposed two fixes (maybe I sent too many emails to the
list...), the second was to fix the scan*.vhdl FPGA code, and reset the
header  data whenever it sets have_header to 0.

The advantage of that fix is that old scan*.bit files will still work (just
not with the 59a6 data), and no fix to the .cpp files need to be applied.

Here's the relavant part of my  email from june the 6th again (reworded):



Another (more backward compatible) fix would be making the bscan code
reset the read header each time it sets "have_header<='0'".

I modified my bscan_s3_spi_isf.vhdl as described below (with the old
59a659a6 magic); and now I can upload files with 59a6 in them (and any
other data I tried).

Here's my bscan_s3_spi_isf.vhdl:
http://tech.komputilo.org/images/1/12/Bscan_s3_spi_isf-reset.vhdl

The relevant part (I had to change a lot more to make it work for my
xcs3s500e FPGA) of the patch is:

@@ -34,6 +38,7 @@
     signal RAM_DO: std_logic_vector(0 downto 0);
     signal RAM_DI: std_logic_vector(0 downto 0);
     signal RAM_WE: std_logic := '0';
+  signal reset_header:std_logic:='0';
 begin

     DRCK1_INV <= not DRCK1;
@@ -142,6 +145,7 @@
             -- disable CSB
             CS_GO <= '0';
             CS_STOP_PREP <= '0';
+      reset_header<='1';  --reset header at next rising clock

             RAM_WADDR <= (others => '0');
             RAM_RADDR <= (others => '0');
@@ -157,7 +161,12 @@
                 RAM_WADDR <= RAM_WADDR + 1;
             end if;

+      reset_header<='0';  --make reset_header 0 the next clock
+      if reset_header='0' then
             header <= header(46 downto 0) & TDI;
+      else
+        header <= (0=> TDI, others=>'0');
+      end if;

             -- enable CSB?
             CS_GO <= CS_GO_PREP;



On 19 June 2013 10:55, Uwe Bonnes
<bo...@el...>wrote:

> Hello,
>
> as joosteto <joo...@gm...> pointed out, there are patterns where our
> bscab_spi code fails. joosteto posted a possible cure, however I have not
> verified yet. Applying the fix however will void all .bit files we have.
>
> How should we cope with that situation?
>
> Any opionions?
>
> Thanks
> --
> Uwe Bonnes                bo...@el...
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Xc3sprog-users mailing list
> Xc3...@li...
> https://lists.sourceforge.net/lists/listinfo/xc3sprog-users
>