Re: Antii, can you give us an update?
- From: Brian Drummond <brian_drummond@xxxxxxxxxxxxx>
- Date: Sat, 05 Apr 2008 13:41:42 +0100
On Fri, 4 Apr 2008 23:56:37 -0700 (PDT), Antti <Antti.Lukats@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.... good...
clocks as well
just a guess but on the information given, it looks plausible to me.
- Brian
.
- Follow-Ups:
- Re: Antii, can you give us an update?
- From: Antti
- Re: Antii, can you give us an update?
- References:
- Antii, can you give us an update?
- From: Nial Stewart
- Re: Antii, can you give us an update?
- From: Antti
- Re: Antii, can you give us an update?
- From: Antti
- Antii, can you give us an update?
- Prev by Date: Re: PLA datasheet - PLS161
- Next by Date: Re: Antii, can you give us an update?
- Previous by thread: Re: Antii, can you give us an update?
- Next by thread: Re: Antii, can you give us an update?
- Index(es):
Relevant Pages
|