Re: Antii, can you give us an update?

On 5 Apr., 14:41, Brian Drummond <brian_drumm...@xxxxxxxxxxxxx> wrote:
On Fri, 4 Apr 2008 23:56:37 -0700 (PDT), Antti <Antti.Luk...@xxxxxxxxxxxxxx>
wrote:



On 2 Apr., 18:22, Antti <Antti.Luk...@xxxxxxxxxxxxxx> wrote:
On 1 Apr., 14:31, "Nial Stewart"

<nial*REMOVE_TH...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
I've read all the posts here but have lost track of how you're
getting on.

Can you post an update and describe what the problem turned out
to be?

Nial.

Quote from Actel website: "In March 2008, it was discovered that a
potential advanced optimization could cause a logic gating of a global
signal.
This is fixed in Libero 8.3 released march 31 2008
updating to 8.3 did not fix the problems, but I am getting closer
status:
in desing exist async strobes A1, A2 (A1 byte rd/wr strobe, A2 spi
slave from ext mcu)

loadable LFSR in A1 domain
2:1 MUX for the selecting the load value
1 input of mux = const, loaded at powerup
2 input of mux connected to 24 bit shift register in A2 domain

LFSR is loaded with constant at powerup, and loaded
with current value in spi shift register ONCE, after
that load the load enable signal is FULLY DISABLED
but when the there is data shifted in into the spi shift
register connected to the input mux of the LFSR load input
then some sequences of data make the LFSR content corrupt

these sequences are REPEATABLE, that is not random!

As I understand it, the SPI register and the LFSR register are on different
clock domains; with purely combinational logic (the mux, and the Load Enable)
between them.

In Xilinx, as I understand it, if a 4-Lut transitions between one
Load_Enable=FALSE state, and another Load_Enable=FALSE state, it is guaranteed
not to glitch via a Load_Enable=True state.

I don't know Actel at all - is the same guarantee true there?

If not, I believe you need an intermediate register (just a simple pipeline
register) clocked in the LFSR clock domain, to hold a copy of the SPI shift
register. (This copy is subject to metastability, but with a tiny window of
opportunity). Whereas now, you are exposed to the possibility of glitches
derived from the SPI clock, and latched on the LFSR clock.

That is the LFSR gets corrupted at certaing
values being visible on the load input via mux

... or certain TRANSITIONS being visible on the load input?

IF the mux and the load enable logic are rolled into the same combinational
cloud, AND 0->0 via glitch 1 is possible, then you are exposed to invalid values
during a settling time window after the ... wrong clock.

I already have forced the LFSR enable and mux select
to global clocks

I'm not sure that helps (it may reduce errors by an order of magnitude or more,
but it leaves you open to the possibility above)

of course the SPI clock and LFSR clocks are global
clocks as well

... good...

just a guess but on the information given, it looks plausible to me.

- Brian

Hi Brian,

the story goes even more fascinating (or frustrating)...

first about Actel - their Logic Cell is NOT LUT based, so the
LUT input transition glitches can not happen (no LUT!) but
actel cell has NO DEDICATED flip-flop, and flip flops are
configured out of logic, and have severe restrictions on
configuration and routing, FF with enable and clear are
made out 2 cells if CLR signal is not driven by global clock
sometimes 4 cells are used to make 1 single flip flop.

the use of global clocks in actel, sometimes its not
"order of magnitude" difference but simple OK vs FAIL 100% issue

case: 64 bit shift register (no enable just shift), clocked with CLEAN
clock at 4mhz

work 100% when FPGA is almost empty (no matter what signal drivers
shift reg clock)
fails 100% when FPGA is >90% and shift clock is ruouted with local
connects

PROVEN. this is also explanaibale, and actel has special appnote for
this (clock skew handling)
==
now to my clocking issue

after taking a break I tried to eliminate things from the problem, so
I stopped shifting data
into the SPI shift register. this however made no difference, and when
i looked again
it was also explanaible as my test counter value was decoded in
external AR MCU
but the bytes holding the counter value did never get back into the
FPGA!

so to summarize again:

1) ARM9 SW has counter, that is used to generate 8 byte encrypted
token
2) those 8 bytes are going into FPGA over A1 parallel interface they
are written into dual port BRAM
3) those 8 bytes are read by AVR over SPI interface
4) AVR decodes those bytes, it also decodes the counter from step 1,
NO ERROR ever here
5) AVR writes 3 bytes to FPGA SPI shift register
6) AVR strobes to load LFSR, and set one time flag that prevents
further LFSR loads
7) ARM9 sends packets in loop (encrypted counter)

now, the counter value NEVER exist inside FPGA
the data passed via FPGA is not decoded there
the data passed via FPGA is not used by the logic responsible for the
load/enable of the LFSR

still at some certain counter value, the LFSR does get corrupted!!
those values are repeatable, they are not random, that is each time
the ARM9 counter is
restarted then at exactly same counter values the LFSR is corrupted.
those values are however different for different PCB+bitstream
combinations

8) AVR puts FPGA into main mode
9) ARM9 sends any packets any number of hours LFSR corruption no
longer happens! no single errror seen

errors happen at [7] at const numbers of counter
error NEVER happen at [9] while streaming random data for hours..

so there is no different transitions on the load input of the LFSR at
all, still there is repeatable dependancy
on the data stream that only passes through FPGA

eeee... [8] what happens there?

well after main mode the AVR no longer collects data from FPGA and no
longer decrypts it.
but that should no have any influence as the decrypt result wasnt
passing into the FPGA anyway.

there is one more difference,
after [8] the LFSR is enabled for 8 clocks lonfer for each packet from
A1 interface

but the LFSR enable/load signals do not share any logic with any of
the data lines !!

Ok, when found out that the counter data is not passing into the load
input at all, i did take a walk
and coffee break, and did write a list of options that can be tested,
list with 6 items, so will work
them out one by one

my bet is that I need add delay on the LFSR enable signal, there is no
explanation why it should
be used as it is already a FF in the same clock domain as the LFSR
clock, but all other items
on my list of possible problems are even less likely (or harder to
test)

Antti
.

Relevant Pages

  • Re: Antii, can you give us an update?
    ... register connected to the input mux of the LFSR load input ... clock domains; with purely combinational logic ... work 100% when FPGA is almost empty (no matter what signal drivers ... but the LFSR enable/load signals do not share any logic with any of ...
    (comp.arch.fpga)
  • Re: 64 bit division compensate NCO
    ... get a new delta phase value for the NCO sounds more like a LOW fidelity ... your clocks are in the range of 1 GHz (and that your fpga can handle clocks ... decreasing clock frequencies. ...
    (comp.arch.fpga)
  • Re: rs232 uart: testbench vs real world, and the missing first letter.
    ... inside the FPGA to do the slow procedural/sequential stuff? ... up to 120MHz clock speed in my Spartan-3. ...   -- let VHDL do the work of computing the divisor! ... I didn't even know what an FFT was ...
    (comp.arch.fpga)
  • Re: Scoping a glitch
    ... 3.3V passes via a 2" ground return wire and 2" signal wire to an FPGA ... "A0") measured at the Digilent board pin, with 1.5cm probe ground to the ... Well if there are ground problems, they are out of my control, as this ... is async vs. the 288kHz qep_simclock causing the trouble. ...
    (comp.arch.fpga)
  • Re: Simulation vs. Hardware mismatch
    ... Just to briefly recap, I have two ctrl ... load <= '0'; ... the clock, tx will change and your output will change. ... sot that those signals all change as soon as the ...
    (comp.arch.fpga)