FPGA Central - World's 1st FPGA / CPLD Portal

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > FPGA

FPGA comp.arch.fpga newsgroup (usenet)

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 10-17-2007, 10:44 PM
Antti
Guest
 
Posts: n/a
Default FPGA quiz3, or where Antti did give up and does not know answer or acceptable workaround

Hi ho

here is code

process (m_sck) begin
if (m_sck'event and m_sck='1') then
do64(62 downto 0) <= do64(62 downto 0) & M_DI;
end if;
end process;
LEDS <= do64s(63 downto 60);

M_DI, M_SCK are driven by external MCU SPI interface.
the MCU send either
0x90 00 00 00 00 00 00 00
or
0x00 00 00 00 00 00 00 00

symptoms: when FPGA is not full, the LED blink, all OFF, 1-0-0-1
when the FPGA is full, there will blink all off, then 1-1-0-1
repeating same pattern, not randomness

changing maxfanout in synplify will change the erratic behaviour but I
have not managed to get the shift register ever work in case where
FPGA is really full.

SPI clock is 4MHz (or lower doesn seem to make any difference)

this time I am giving up, that is not trying to force the shift
register to work, but find solution that works

the problem only occourcs on Actel FPGA, and yes yes it works in
símulation it works in xilinx FPGA, etc..

Antti
who this time really doesnt know the solution

Reply With Quote
  #2 (permalink)  
Old 10-17-2007, 11:15 PM
Dave
Guest
 
Posts: n/a
Default Re: FPGA quiz3, or where Antti did give up and does not know answer or acceptable workaround

Antti,

Could you fix the typo on the line with the do64(62 downto 0)
assignment - there's an array length mismatch. Also, what is the
definition of do64 - std_logic_vector(63 downto 0)?

On Oct 17, 4:44 pm, Antti <[email protected]> wrote:
> Hi ho
>
> here is code
>
> process (m_sck) begin
> if (m_sck'event and m_sck='1') then
> do64(62 downto 0) <= do64(62 downto 0) & M_DI;
> end if;
> end process;
> LEDS <= do64s(63 downto 60);
>
> M_DI, M_SCK are driven by external MCU SPI interface.
> the MCU send either
> 0x90 00 00 00 00 00 00 00
> or
> 0x00 00 00 00 00 00 00 00
>
> symptoms: when FPGA is not full, the LED blink, all OFF, 1-0-0-1
> when the FPGA is full, there will blink all off, then 1-1-0-1
> repeating same pattern, not randomness
>
> changing maxfanout in synplify will change the erratic behaviour but I
> have not managed to get the shift register ever work in case where
> FPGA is really full.
>
> SPI clock is 4MHz (or lower doesn seem to make any difference)
>
> this time I am giving up, that is not trying to force the shift
> register to work, but find solution that works
>
> the problem only occourcs on Actel FPGA, and yes yes it works in
> símulation it works in xilinx FPGA, etc..
>
> Antti
> who this time really doesnt know the solution



Reply With Quote
  #3 (permalink)  
Old 10-17-2007, 11:19 PM
Antti
Guest
 
Posts: n/a
Default Re: FPGA quiz3, or where Antti did give up and does not know answer or acceptable workaround

On 17 Okt., 23:15, Dave <[email protected]> wrote:
> Antti,
>
> Could you fix the typo on the line with the do64(62 downto 0)
> assignment - there's an array length mismatch. Also, what is the
> definition of do64 - std_logic_vector(63 downto 0)?
>
> On Oct 17, 4:44 pm, Antti <[email protected]> wrote:
>
>
>
> > Hi ho

>
> > here is code

>
> > process (m_sck) begin
> > if (m_sck'event and m_sck='1') then
> > do64(62 downto 0) <= do64(62 downto 0) & M_DI;
> > end if;
> > end process;
> > LEDS <= do64s(63 downto 60);

>
> > M_DI, M_SCK are driven by external MCU SPI interface.
> > the MCU send either
> > 0x90 00 00 00 00 00 00 00
> > or
> > 0x00 00 00 00 00 00 00 00

>
> > symptoms: when FPGA is not full, the LED blink, all OFF, 1-0-0-1
> > when the FPGA is full, there will blink all off, then 1-1-0-1
> > repeating same pattern, not randomness

>
> > changing maxfanout in synplify will change the erratic behaviour but I
> > have not managed to get the shift register ever work in case where
> > FPGA is really full.

>
> > SPI clock is 4MHz (or lower doesn seem to make any difference)

>
> > this time I am giving up, that is not trying to force the shift
> > register to work, but find solution that works

>
> > the problem only occourcs on Actel FPGA, and yes yes it works in
> > símulation it works in xilinx FPGA, etc..

>
> > Antti
> > who this time really doesnt know the solution - Zitierten Text ausblenden -

>
> - Zitierten Text anzeigen -


sorry my eyes see double(almost, just hurt), i cleaned the code and
madetypo

signal do64 : std_logic_vector(63 downto 0) ;


process (m_sck) begin
if (m_sck'event and m_sck='1') then
do64(63 downto 0) <= do64(62 downto 0) & M_DI;
end if;
end process;
LEDS <= do64(63 downto 60);






Reply With Quote
  #4 (permalink)  
Old 10-18-2007, 03:12 AM
Mark McDougall
Guest
 
Posts: n/a
Default Re: FPGA quiz3, or where Antti did give up and does not know answeror acceptable workaround

Antti wrote:

> signal do64 : std_logic_vector(63 downto 0) ;
> process (m_sck) begin
> if (m_sck'event and m_sck='1') then
> do64(63 downto 0) <= do64(62 downto 0) & M_DI;
> end if;
> end process;
> LEDS <= do64(63 downto 60);


What a maintenance nightmare!!

process (m_sck)
variable do64 : std_logic_vector(63 downto 0);
begin
if m_sck'event and m_sck = '1' then
do64 := do64(do64'left-1 downto 0) & M_DI;
end if;
LEDS <= do64(do64'left downto do64'left-3);
end process;

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266
Reply With Quote
  #5 (permalink)  
Old 10-18-2007, 03:19 AM
Mark McDougall
Guest
 
Posts: n/a
Default Re: FPGA quiz3, or where Antti did give up and does not know answeror acceptable workaround

Antti wrote:

> M_DI, M_SCK are driven by external MCU SPI interface.


Sounds to me like you've got skew between M_DI & M_SCK at the
shift-register clk, data inputs.

Your evidence suggests that M_DI lags M_SCK... can you super-sample the
inputs (they're only 4MHz) and adjust for the skew internally?

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266
Reply With Quote
  #6 (permalink)  
Old 10-18-2007, 07:50 AM
Antti
Guest
 
Posts: n/a
Default Re: FPGA quiz3, or where Antti did give up and does not know answer or acceptable workaround

On 18 Okt., 03:19, Mark McDougall <[email protected]> wrote:
> Antti wrote:
> > M_DI, M_SCK are driven by external MCU SPI interface.

>
> Sounds to me like you've got skew between M_DI & M_SCK at the
> shift-register clk, data inputs.
>
> Your evidence suggests that M_DI lags M_SCK... can you super-sample the
> inputs (they're only 4MHz) and adjust for the skew internally?
>
> Regards,
>
> --
> Mark McDougall, Engineer
> Virtual Logic Pty Ltd, <http://www.vl.com.au>
> 21-25 King St, Rockdale, 2216
> Ph: +612-9599-3255 Fax: +612-9599-3266


Mark,

I was evidencing the complete design to fail to operate in the target
FPGA
same design was known to work in simulation and in other FPGA family
as well.

the 4MHz SPI signals are "near perfect" there is the clock alignment
on the inputs is defenetly perfect.
I a sampling at correct clock edge as well. The SPI clock shows little
overshoot but thats all

now what made the puzzle harder, at initial testing when i wasnt 100%
of the SPI modes, etc, it
looked like the 64 bit register would hold correct value, 1 bit
shifted, as if the SPI master sends
always 1 extra clock. to correct this and aligne data I did take added
flip flop. stupid, but it seemed
to work. and yes i had to add the 65th clock pulse in simulation
testbench too. After that it looked like ok.
but the complete design still failed to fully operate.

now, the upper 4 bits of the register are used to "change mode"
depending on the value, the mode change
did not work. as FPGA has been is 80-98% full, so I used LEDs and
UJTAG for debugging. connected
"mode detect" to LED, wrong, then connected mode_detect to UIREG6 -
this is where the problem described
in quiz1 appeared!!

before going totally nuts, I finally removed the rest of the logic
around the shift the register, and the it
id start to work and shift properly.

playing around with maxfanout and global treshold in Synplify does
seem to have influence how wrong
the shift register shifts, but I had to time to go on forever trying
to find a fanout-treshold values that would
make all work.

during testing with 4LED on shiftregister in big design, when it
failed the same wrong (1-1-0-1 instead 1-0-0-1)
patter was observable in all supply range where the board did stay
operational, to my surprise the PCB
FPGA+AVR MCU did work down to 1.7V and down to 1.7V the shift-led did
show 1101 so the huge supply
variation did make a difference. I assume the AVR generated signal did
change a lot in amplitude, slew, overshoot, etc at lower supply, also
AVR clock lowered maybe 2 times, but that all did not make any
difference.
so whatever causes the bad shift its very stable in given P&R run.

as I said, I have no plausible explanation or cure.
I did give up, and optimized the 64 bit register (it was holding a
blowfish key challenge) away - and problem has disappeared as well.

but it leaves an un-easy feeling, if the FPGA was working wrong
because of unexplained reason, the same or similar reason could cause
new trouble somewhere else too.

the big desing has 1 parallell, 2 SPI slave, 2 SPI master, 1 sd card
master interface, 6 global and 1 quadrant clock are used

there is 50MHz free running clock, yes I tried to oversample and
moreover glitch filter the SPI clock for the failing register, first
trial did not give any result or improvement, and I did give up on
that direction, the direct clocking looked as working better

Antti

Reply With Quote
  #7 (permalink)  
Old 10-18-2007, 09:37 AM
Guest
 
Posts: n/a
Default Re: FPGA quiz3, or where Antti did give up and does not know answer or acceptable workaround

On 17 Oct, 21:44, Antti <[email protected]> wrote:
> Hi ho
>
> here is code
>
> process (m_sck) begin
> if (m_sck'event and m_sck='1') then
> do64(62 downto 0) <= do64(62 downto 0) & M_DI;
> end if;
> end process;
> LEDS <= do64s(63 downto 60);
>
> M_DI, M_SCK are driven by external MCU SPI interface.
> the MCU send either
> 0x90 00 00 00 00 00 00 00
> or
> 0x00 00 00 00 00 00 00 00
>
> symptoms: when FPGA is not full, the LED blink, all OFF, 1-0-0-1
> when the FPGA is full, there will blink all off, then 1-1-0-1
> repeating same pattern, not randomness
>
> changing maxfanout in synplify will change the erratic behaviour but I
> have not managed to get the shift register ever work in case where
> FPGA is really full.
>
> SPI clock is 4MHz (or lower doesn seem to make any difference)
>
> this time I am giving up, that is not trying to force the shift
> register to work, but find solution that works
>
> the problem only occourcs on Actel FPGA, and yes yes it works in
> símulation it works in xilinx FPGA, etc..
>
> Antti
> who this time really doesnt know the solution


So is m_sck actually using global routing, or has it been routed
normally?

I've seen similar problems when clocks have been routed using local
nets. I would suggest forcing m_sck to use a global net, or since
your using Actel you could force it on to one of the local global
spines. I can't remember how to do it, but I know there is an app
note saying what constraints are needed.

Neill.

Reply With Quote
  #8 (permalink)  
Old 10-18-2007, 09:37 AM
Kim Enkovaara
Guest
 
Posts: n/a
Default Re: FPGA quiz3, or where Antti did give up and does not know answeror acceptable workaround

Antti wrote:

> but it leaves an un-easy feeling, if the FPGA was working wrong
> because of unexplained reason, the same or similar reason could cause
> new trouble somewhere else too.


Did you check the final results Synplify generated (technology mapping)
and if that result was sane. At least Synplify 8.8 was unusable due
to many bugs. S 8.6.2 and 8.9 seem to be better in terms of creating
working chips.

--Kim
Reply With Quote
  #9 (permalink)  
Old 10-18-2007, 09:49 AM
Antti
Guest
 
Posts: n/a
Default Re: FPGA quiz3, or where Antti did give up and does not know answer or acceptable workaround

On 18 Okt., 09:37, Kim Enkovaara <[email protected]> wrote:
> Antti wrote:
> > but it leaves an un-easy feeling, if the FPGA was working wrong
> > because of unexplained reason, the same or similar reason could cause
> > new trouble somewhere else too.

>
> Did you check the final results Synplify generated (technology mapping)
> and if that result was sane. At least Synplify 8.8 was unusable due
> to many bugs. S 8.6.2 and 8.9 seem to be better in terms of creating
> working chips.
>
> --Kim


the failing desing was made with S 8.8A1 and was not tested with other
version of synthesis tools

after my quiz1 issue, that looked like tool error or faulty FPGA, I
was not to belive that another problem so close the first one is
related to tools making a mess, so I was very hard trying to find
problem in my design.

I have made backup of the "known failing with 8.8" design, when i have
time, i will retest it with 8.6.2

I did look actel technology view, and did not see anything totally
wrong at quick look, but i also did not fully look it over as the
signals are hard to follow

and thanks a zillion - the suggestion that "8.8 was unusable" it is
golden already, it gives hope that the problem is solvable

Antti

Reply With Quote
  #10 (permalink)  
Old 10-18-2007, 09:54 AM
Antti
Guest
 
Posts: n/a
Default Re: FPGA quiz3, or where Antti did give up and does not know answer or acceptable workaround

On 18 Okt., 09:37, [email protected] wrote:
> On 17 Oct, 21:44, Antti <[email protected]> wrote:
>
>
>
>
>
> > Hi ho

>
> > here is code

>
> > process (m_sck) begin
> > if (m_sck'event and m_sck='1') then
> > do64(62 downto 0) <= do64(62 downto 0) & M_DI;
> > end if;
> > end process;
> > LEDS <= do64s(63 downto 60);

>
> > M_DI, M_SCK are driven by external MCU SPI interface.
> > the MCU send either
> > 0x90 00 00 00 00 00 00 00
> > or
> > 0x00 00 00 00 00 00 00 00

>
> > symptoms: when FPGA is not full, the LED blink, all OFF, 1-0-0-1
> > when the FPGA is full, there will blink all off, then 1-1-0-1
> > repeating same pattern, not randomness

>
> > changing maxfanout in synplify will change the erratic behaviour but I
> > have not managed to get the shift register ever work in case where
> > FPGA is really full.

>
> > SPI clock is 4MHz (or lower doesn seem to make any difference)

>
> > this time I am giving up, that is not trying to force the shift
> > register to work, but find solution that works

>
> > the problem only occourcs on Actel FPGA, and yes yes it works in
> > símulation it works in xilinx FPGA, etc..

>
> > Antti
> > who this time really doesnt know the solution

>
> So is m_sck actually using global routing, or has it been routed
> normally?
>
> I've seen similar problems when clocks have been routed using local
> nets. I would suggest forcing m_sck to use a global net, or since
> your using Actel you could force it on to one of the local global
> spines. I can't remember how to do it, but I know there is an app
> note saying what constraints are needed.
>
> Neill.- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -


with defaul maxfanout of 12 synplify insert some 5 buffer in the M_SCK
path
global clocks are all used, because of routing constraints some set-
reset nets need to be driven by global nets otherise designer will use
2 cells for 1 flip flop, the FPGA is very full so I used the global
nets first to optimize for smallest FPGA resource useage.

but - global or not, a 64 bit shift register clocked at 4MHz should
work in ANY modern FPGA no matter what.
there can not be any setup or hold violation. and the same erratic
shift was also happening at even lower clock, below 2MHz.

and yes I play some more with the global nets, they seem to be a key
in Actel technology.

Antti

Reply With Quote
  #11 (permalink)  
Old 10-18-2007, 11:00 AM
Jim Granville
Guest
 
Posts: n/a
Default Re: FPGA quiz3, or where Antti did give up and does not know answeror acceptable workaround

Antti wrote:
> but - global or not, a 64 bit shift register clocked at 4MHz should
> work in ANY modern FPGA no matter what.
> there can not be any setup or hold violation. and the same erratic
> shift was also happening at even lower clock, below 2MHz.
>
> and yes I play some more with the global nets, they seem to be a key
> in Actel technology.


If this is clocked from a uC, one thing you could do, is add
a loop readback - where you either simply use the SR as
a delay line, and check you get back what left 64 clocks ago,
or add a Load option, so you can read back any latched nodes,
to verify their content ?

-jg

Reply With Quote
  #12 (permalink)  
Old 10-18-2007, 12:44 PM
Antti
Guest
 
Posts: n/a
Default Re: FPGA quiz3, or where Antti did give up and does not know answer or acceptable workaround

On 18 Okt., 11:00, Jim Granville <[email protected]>
wrote:
> Antti wrote:
> > but - global or not, a 64 bit shift register clocked at 4MHz should
> > work in ANY modern FPGA no matter what.
> > there can not be any setup or hold violation. and the same erratic
> > shift was also happening at even lower clock, below 2MHz.

>
> > and yes I play some more with the global nets, they seem to be a key
> > in Actel technology.

>
> If this is clocked from a uC, one thing you could do, is add
> a loop readback - where you either simply use the SR as
> a delay line, and check you get back what left 64 clocks ago,
> or add a Load option, so you can read back any latched nodes,
> to verify their content ?
>
> -jg


Hi Jim,

yes I can add the readback path, its available, but well 4 LED on the
shift register if they are wrong, then something is wrong.

the story seems to be more and more a problem
yesterday ONE P&R worked it used 28 bit register not 64

today I did rerung the desing from yesterday (with 28 shift reg) with
Synplify 8.9
and i see the same wrong pattern 1011 (not 1001) on the LEDs again!
same behaviour 2 different PCB
when I take the programming file from yesterday it works.
simple re-run P&R version doesnt.

so it doesnt seem to be synplify issue as versions 8.8 and 8.9 seem to
have same behaviour.

I was so happy yesterday when the shorter shift register worked that I
did not test multiply P&R runs
but now i am stuck again.
ok, I can convert the 24 shift to 1 shift 8 and 2 latches, etc..

but the puzzle remains!

Antti






















Reply With Quote
  #13 (permalink)  
Old 10-18-2007, 12:47 PM
Marc Randolph
Guest
 
Posts: n/a
Default Re: FPGA quiz3, or where Antti did give up and does not know answer or acceptable workaround

On Oct 17, 4:19 pm, Antti <[email protected]> wrote:
> On 17 Okt., 23:15, Dave <[email protected]> wrote:
>
>
>
> > Antti,

>
> > Could you fix the typo on the line with the do64(62 downto 0)
> > assignment - there's an array length mismatch. Also, what is the
> > definition of do64 - std_logic_vector(63 downto 0)?

>
> > On Oct 17, 4:44 pm, Antti <[email protected]> wrote:

>
> > > Hi ho

>
> > > here is code

>
> > > process (m_sck) begin
> > > if (m_sck'event and m_sck='1') then
> > > do64(62 downto 0) <= do64(62 downto 0) & M_DI;
> > > end if;
> > > end process;
> > > LEDS <= do64s(63 downto 60);

>
> > > M_DI, M_SCK are driven by external MCU SPI interface.
> > > the MCU send either
> > > 0x90 00 00 00 00 00 00 00
> > > or
> > > 0x00 00 00 00 00 00 00 00

>
> > > symptoms: when FPGA is not full, the LED blink, all OFF, 1-0-0-1
> > > when the FPGA is full, there will blink all off, then 1-1-0-1
> > > repeating same pattern, not randomness

>
> > > changing maxfanout in synplify will change the erratic behaviour but I
> > > have not managed to get the shift register ever work in case where
> > > FPGA is really full.

>
> > > SPI clock is 4MHz (or lower doesn seem to make any difference)

>
> > > this time I am giving up, that is not trying to force the shift
> > > register to work, but find solution that works

>
> > > the problem only occourcs on Actel FPGA, and yes yes it works in
> > > símulation it works in xilinx FPGA, etc..

>
> > > Antti
> > > who this time really doesnt know the solution - Zitierten Text ausblenden -

>
> > - Zitierten Text anzeigen -

>
> sorry my eyes see double(almost, just hurt), i cleaned the code and
> madetypo
>
> signal do64 : std_logic_vector(63 downto 0) ;
>
> process (m_sck) begin
> if (m_sck'event and m_sck='1') then
> do64(63 downto 0) <= do64(62 downto 0) & M_DI;
> end if;
> end process;
> LEDS <= do64(63 downto 60);


The code seems pretty straight forward. One question though: are you
expecting the groups of four output bits to line up on some magical
boundary? If so, you'd obviously need a sync or reset pulse.

Ignoring the four bit alignment, is m_sck landing on the dedicated
clocking resources of the Actel part? If so, I'm guessing your
problem has nothing to do with the the shift register code. What is
the toggle rates of m_sck compared to M_DI, and just as important, the
clock to data alignment between the two? Have you brought m_sclk out
an I/O pin to verify its frequency and phase relationship with M_DI?
Brought M_DI back out an I/O pin after being sampled by m_sck to
verify that it's being sampled correctly?

Have fun,

Marc

Reply With Quote
  #14 (permalink)  
Old 10-18-2007, 12:55 PM
Antti
Guest
 
Posts: n/a
Default Re: FPGA quiz3, or where Antti did give up and does not know answer or acceptable workaround

On 18 Okt., 12:47, Marc Randolph <[email protected]> wrote:
> On Oct 17, 4:19 pm, Antti <[email protected]> wrote:
>
>
>
>
>
> > On 17 Okt., 23:15, Dave <[email protected]> wrote:

>
> > > Antti,

>
> > > Could you fix the typo on the line with the do64(62 downto 0)
> > > assignment - there's an array length mismatch. Also, what is the
> > > definition of do64 - std_logic_vector(63 downto 0)?

>
> > > On Oct 17, 4:44 pm, Antti <[email protected]> wrote:

>
> > > > Hi ho

>
> > > > here is code

>
> > > > process (m_sck) begin
> > > > if (m_sck'event and m_sck='1') then
> > > > do64(62 downto 0) <= do64(62 downto 0) & M_DI;
> > > > end if;
> > > > end process;
> > > > LEDS <= do64s(63 downto 60);

>
> > > > M_DI, M_SCK are driven by external MCU SPI interface.
> > > > the MCU send either
> > > > 0x90 00 00 00 00 00 00 00
> > > > or
> > > > 0x00 00 00 00 00 00 00 00

>
> > > > symptoms: when FPGA is not full, the LED blink, all OFF, 1-0-0-1
> > > > when the FPGA is full, there will blink all off, then 1-1-0-1
> > > > repeating same pattern, not randomness

>
> > > > changing maxfanout in synplify will change the erratic behaviour but I
> > > > have not managed to get the shift register ever work in case where
> > > > FPGA is really full.

>
> > > > SPI clock is 4MHz (or lower doesn seem to make any difference)

>
> > > > this time I am giving up, that is not trying to force the shift
> > > > register to work, but find solution that works

>
> > > > the problem only occourcs on Actel FPGA, and yes yes it works in
> > > > símulation it works in xilinx FPGA, etc..

>
> > > > Antti
> > > > who this time really doesnt know the solution - Zitierten Text ausblenden -

>
> > > - Zitierten Text anzeigen -

>
> > sorry my eyes see double(almost, just hurt), i cleaned the code and
> > madetypo

>
> > signal do64 : std_logic_vector(63 downto 0) ;

>
> > process (m_sck) begin
> > if (m_sck'event and m_sck='1') then
> > do64(63 downto 0) <= do64(62 downto 0) & M_DI;
> > end if;
> > end process;
> > LEDS <= do64(63 downto 60);

>
> The code seems pretty straight forward. One question though: are you
> expecting the groups of four output bits to line up on some magical
> boundary? If so, you'd obviously need a sync or reset pulse.
>
> Ignoring the four bit alignment, is m_sck landing on the dedicated
> clocking resources of the Actel part? If so, I'm guessing your
> problem has nothing to do with the the shift register code. What is
> the toggle rates of m_sck compared to M_DI, and just as important, the
> clock to data alignment between the two? Have you brought m_sclk out
> an I/O pin to verify its frequency and phase relationship with M_DI?
> Brought M_DI back out an I/O pin after being sampled by m_sck to
> verify that it's being sampled correctly?
>
> Have fun,
>
> Marc- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -


the M_SCK and M_DI phase relation is perfect.

there is no change in (wrong) behavour depending on the M_SCK
frequency, 4Mhz, 500Khz exactly the same odd behaviour

after the shit there is sync pulse to latch the values
but its not related the the sync or SPI select, if I disable all sync
and select signal switching the odd behaviour remains

I send 0x00 then wait 1 second
send then 0x90 and I see 2 LED on not 1

I have 1 P&R run, that works, all previous and later bitstream files
have odd behaviour

the fun way past gone in this game. need get it working one way or
another.

Antti


















Reply With Quote
  #15 (permalink)  
Old 10-18-2007, 01:30 PM
Brian Davis
Guest
 
Posts: n/a
Default Re: FPGA quiz3, or where Antti did give up and does not know answer or acceptable workaround

Antti wrote:
>
> but - global or not, a 64 bit shift register clocked at 4MHz should
> work in ANY modern FPGA no matter what.
> there can not be any setup or hold violation. and the same erratic
> shift was also happening at even lower clock, below 2MHz.
>


Not true : if it is an internal hold problem due to your use of local
routing for a clock, the problem will happen at ANY clock frequency
( i.e., the data from bit N-1 is getting to bit N before the clock )

I'd expect Neill's suggestion to use a clock spline would fix the
problem.

If you can't manage to convince the tools to use a clock spline, a
hack to
work around the problem would be to stick some dummy logic (made un-
optimizable
somehow) between each bit of the shift register to slow down the data
path.

Brian

Reply With Quote
  #16 (permalink)  
Old 10-18-2007, 01:37 PM
Antti
Guest
 
Posts: n/a
Default Re: FPGA quiz3, or where Antti did give up and does not know answer or acceptable workaround

On 18 Okt., 13:30, Brian Davis <[email protected]> wrote:
> Antti wrote:
>
> > but - global or not, a 64 bit shift register clocked at 4MHz should
> > work in ANY modern FPGA no matter what.
> > there can not be any setup or hold violation. and the same erratic
> > shift was also happening at even lower clock, below 2MHz.

>
> Not true : if it is an internal hold problem due to your use of local
> routing for a clock, the problem will happen at ANY clock frequency
> ( i.e., the data from bit N-1 is getting to bit N before the clock )
>
> I'd expect Neill's suggestion to use a clock spline would fix the
> problem.
>
> If you can't manage to convince the tools to use a clock spline, a
> hack to
> work around the problem would be to stick some dummy logic (made un-
> optimizable
> somehow) between each bit of the shift register to slow down the data
> path.
>
> Brian


yes me stupid
already fix

Antti



Reply With Quote
  #17 (permalink)  
Old 10-18-2007, 01:38 PM
John McCaskill
Guest
 
Posts: n/a
Default Re: FPGA quiz3, or where Antti did give up and does not know answer or acceptable workaround

On Oct 18, 2:54 am, Antti <[email protected]> wrote:
> On 18 Okt., 09:37, [email protected] wrote:
>
>
>
> > On 17 Oct, 21:44, Antti <[email protected]> wrote:

>
> > > Hi ho

>
> > > here is code

>
> > > process (m_sck) begin
> > > if (m_sck'event and m_sck='1') then
> > > do64(62 downto 0) <= do64(62 downto 0) & M_DI;
> > > end if;
> > > end process;
> > > LEDS <= do64s(63 downto 60);

>
> > > M_DI, M_SCK are driven by external MCU SPI interface.
> > > the MCU send either
> > > 0x90 00 00 00 00 00 00 00
> > > or
> > > 0x00 00 00 00 00 00 00 00

>
> > > symptoms: when FPGA is not full, the LED blink, all OFF, 1-0-0-1
> > > when the FPGA is full, there will blink all off, then 1-1-0-1
> > > repeating same pattern, not randomness

>
> > > changing maxfanout in synplify will change the erratic behaviour but I
> > > have not managed to get the shift register ever work in case where
> > > FPGA is really full.

>
> > > SPI clock is 4MHz (or lower doesn seem to make any difference)

>
> > > this time I am giving up, that is not trying to force the shift
> > > register to work, but find solution that works

>
> > > the problem only occourcs on Actel FPGA, and yes yes it works in
> > > símulation it works in xilinx FPGA, etc..

>
> > > Antti
> > > who this time really doesnt know the solution

>
> > So is m_sck actually using global routing, or has it been routed
> > normally?

>
> > I've seen similar problems when clocks have been routed using local
> > nets. I would suggest forcing m_sck to use a global net, or since
> > your using Actel you could force it on to one of the local global
> > spines. I can't remember how to do it, but I know there is an app
> > note saying what constraints are needed.

>
> > Neill.- Zitierten Text ausblenden -

>
> > - Zitierten Text anzeigen -

>
> with defaul maxfanout of 12 synplify insert some 5 buffer in the M_SCK
> path
> global clocks are all used, because of routing constraints some set-
> reset nets need to be driven by global nets otherise designer will use
> 2 cells for 1 flip flop, the FPGA is very full so I used the global
> nets first to optimize for smallest FPGA resource useage.
>
> but - global or not, a 64 bit shift register clocked at 4MHz should
> work in ANY modern FPGA no matter what.
> there can not be any setup or hold violation. and the same erratic
> shift was also happening at even lower clock, below 2MHz.
>
> and yes I play some more with the global nets, they seem to be a key
> in Actel technology.
>
> Antti



Hello Antii,

It does not matter how slow you clock it, you can still have hold
violations if the clock skew between a source and destination register
exceeds the data path delay from the source to the destination, and
the clock arrives at the destination after it arrives at the source.

Since a problem like this would be dependent on the place and route
results, it sounds like it fits your symptoms.

Have you run static timing analysis on this design?

Your console looks interesting. I had recently been looking at the
One Laptop Per Child web site, so it occurred to me that you must be
working on your own One Console Per Child project. The nice thing
about that is there is no need for it to be a non-profit. OCPC is the
natural steady state of the world. Or maybe its two. Or three?

Regards,

John McCaskill
www.fastertechnology.com

Reply With Quote
  #18 (permalink)  
Old 10-18-2007, 01:42 PM
Antti
Guest
 
Posts: n/a
Default Re: FPGA quiz3, or where Antti did give up and does not know answer or acceptable workaround

On 18 Okt., 12:44, Antti <[email protected]> wrote:
> On 18 Okt., 11:00, Jim Granville <[email protected]>
> wrote:
>
>
>
>
>
> > Antti wrote:
> > > but - global or not, a 64 bit shift register clocked at 4MHz should
> > > work in ANY modern FPGA no matter what.
> > > there can not be any setup or hold violation. and the same erratic
> > > shift was also happening at even lower clock, below 2MHz.

>
> > > and yes I play some more with the global nets, they seem to be a key
> > > in Actel technology.

>
> > If this is clocked from a uC, one thing you could do, is add
> > a loop readback - where you either simply use the SR as
> > a delay line, and check you get back what left 64 clocks ago,
> > or add a Load option, so you can read back any latched nodes,
> > to verify their content ?

>
> > -jg

>
> Hi Jim,
>
> yes I can add the readback path, its available, but well 4 LED on the
> shift register if they are wrong, then something is wrong.
>
> the story seems to be more and more a problem
> yesterday ONE P&R worked it used 28 bit register not 64
>
> today I did rerung the desing from yesterday (with 28 shift reg) with
> Synplify 8.9
> and i see the same wrong pattern 1011 (not 1001) on the LEDs again!
> same behaviour 2 different PCB
> when I take the programming file from yesterday it works.
> simple re-run P&R version doesnt.
>
> so it doesnt seem to be synplify issue as versions 8.8 and 8.9 seem to
> have same behaviour.
>
> I was so happy yesterday when the shorter shift register worked that I
> did not test multiply P&R runs
> but now i am stuck again.
> ok, I can convert the 24 shift to 1 shift 8 and 2 latches, etc..
>
> but the puzzle remains!
>
> Antti- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -


Ok, this time it looks like solved. feel sosososoo stuuupid.
of course the internal skew of clocks is important, so adding manually
a global clock buffer seem have cured that. still pending of longer
testing, but it looks like ok now.

what made me wonder was that the "wrong" pattern was always the same,
across multiply P&R runs.
I assumed wrongly that mockup of the internal clock can have
repeateable same failure, and specially
on register lengts 64 and 28, same wrong pattern 1001 > 1011 !!

there was NO PRIZE offered for this quiz3 as I did not know the
solution, but I received private mail, what was helpful, that email
arrived some minutes after I had forced a globabl buffer into the
design myself, but I do consider it fair to offer similar prize to
that party also.

that email just told me to force the global net, with good reasoning
for that.

Antti is feeling little stupid but also little happier (in the hope
the quiz3 issue is really solved)

Reply With Quote
  #19 (permalink)  
Old 10-18-2007, 02:16 PM
Antti
Guest
 
Posts: n/a
Default Re: FPGA quiz3, or where Antti did give up and does not know answer or acceptable workaround

On 18 Okt., 13:38, John McCaskill <[email protected]> wrote:
> On Oct 18, 2:54 am, Antti <[email protected]> wrote:
>
>
>
>
>
> > On 18 Okt., 09:37, [email protected] wrote:

>
> > > On 17 Oct, 21:44, Antti <[email protected]> wrote:

>
> > > > Hi ho

>
> > > > here is code

>
> > > > process (m_sck) begin
> > > > if (m_sck'event and m_sck='1') then
> > > > do64(62 downto 0) <= do64(62 downto 0) & M_DI;
> > > > end if;
> > > > end process;
> > > > LEDS <= do64s(63 downto 60);

>
> > > > M_DI, M_SCK are driven by external MCU SPI interface.
> > > > the MCU send either
> > > > 0x90 00 00 00 00 00 00 00
> > > > or
> > > > 0x00 00 00 00 00 00 00 00

>
> > > > symptoms: when FPGA is not full, the LED blink, all OFF, 1-0-0-1
> > > > when the FPGA is full, there will blink all off, then 1-1-0-1
> > > > repeating same pattern, not randomness

>
> > > > changing maxfanout in synplify will change the erratic behaviour but I
> > > > have not managed to get the shift register ever work in case where
> > > > FPGA is really full.

>
> > > > SPI clock is 4MHz (or lower doesn seem to make any difference)

>
> > > > this time I am giving up, that is not trying to force the shift
> > > > register to work, but find solution that works

>
> > > > the problem only occourcs on Actel FPGA, and yes yes it works in
> > > > símulation it works in xilinx FPGA, etc..

>
> > > > Antti
> > > > who this time really doesnt know the solution

>
> > > So is m_sck actually using global routing, or has it been routed
> > > normally?

>
> > > I've seen similar problems when clocks have been routed using local
> > > nets. I would suggest forcing m_sck to use a global net, or since
> > > your using Actel you could force it on to one of the local global
> > > spines. I can't remember how to do it, but I know there is an app
> > > note saying what constraints are needed.

>
> > > Neill.- Zitierten Text ausblenden -

>
> > > - Zitierten Text anzeigen -

>
> > with defaul maxfanout of 12 synplify insert some 5 buffer in the M_SCK
> > path
> > global clocks are all used, because of routing constraints some set-
> > reset nets need to be driven by global nets otherise designer will use
> > 2 cells for 1 flip flop, the FPGA is very full so I used the global
> > nets first to optimize for smallest FPGA resource useage.

>
> > but - global or not, a 64 bit shift register clocked at 4MHz should
> > work in ANY modern FPGA no matter what.
> > there can not be any setup or hold violation. and the same erratic
> > shift was also happening at even lower clock, below 2MHz.

>
> > and yes I play some more with the global nets, they seem to be a key
> > in Actel technology.

>
> > Antti

>
> Hello Antii,
>
> It does not matter how slow you clock it, you can still have hold
> violations if the clock skew between a source and destination register
> exceeds the data path delay from the source to the destination, and
> the clock arrives at the destination after it arrives at the source.
>
> Since a problem like this would be dependent on the place and route
> results, it sounds like it fits your symptoms.
>
> Have you run static timing analysis on this design?
>
> Your console looks interesting. I had recently been looking at the
> One Laptop Per Child web site, so it occurred to me that you must be
> working on your own One Console Per Child project. The nice thing
> about that is there is no need for it to be a non-profit. OCPC is the
> natural steady state of the world. Or maybe its two. Or three?
>
> Regards,
>
> John McCaskillwww.fastertechnology.com- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -


Hi John,

read my other reply. no this problem did not happen with the xilinx
FPGA.

I am working towards: "Mission impossible II (tecnical)" in my life.

Once i have achived (something technical) that i would consider
impossible havent I had done it.

my MI-2(tech.) involves developing an ASIC replacement with FPGA
technology with total BOM cost limit of 6.00 USD. Additional
constraints like little PCB space, memory latency requirments, etc
apply. You can imagine things happen on that path. I am pushing a very
small FPGA to its limits, and forgot the obvious. Also the struggle
with the quiz1 problem did eat a lot of my brains, and I havent had my
1-per-year-take-a-longer-breath yet this year.

thanks for nice comment on the console. I hope it will have a small
fun club, specially as OCPC-1 is targetting sale price below 20 USD

Antti

Reply With Quote
  #20 (permalink)  
Old 10-18-2007, 09:01 PM
Jim Granville
Guest
 
Posts: n/a
Default Re: FPGA quiz3, or where Antti did give up and does not know answeror acceptable workaround

Antti wrote:

> Ok, this time it looks like solved. feel sosososoo stuuupid.
> of course the internal skew of clocks is important, so adding manually
> a global clock buffer seem have cured that. still pending of longer
> testing, but it looks like ok now.


So you are saying that todays FPGA fabrics (which one again here ?)
now have such routing delays, (and fast registers) that Tco is less
than Troute, and can violate Tsu/Th ?

Maybe a longer shifter literally takes more room, so statistically
has more chance of long/short routes in the wrong combination ?

If you run post route sim, does that flag any issues
- ideally it should, right

-jg


Reply With Quote
  #21 (permalink)  
Old 10-18-2007, 10:54 PM
Antti
Guest
 
Posts: n/a
Default Re: FPGA quiz3, or where Antti did give up and does not know answer or acceptable workaround

On 18 Okt., 21:01, Jim Granville <[email protected]>
wrote:
> Antti wrote:
> > Ok, this time it looks like solved. feel sosososoo stuuupid.
> > of course the internal skew of clocks is important, so adding manually
> > a global clock buffer seem have cured that. still pending of longer
> > testing, but it looks like ok now.

>
> So you are saying that todays FPGA fabrics (which one again here ?)
> now have such routing delays, (and fast registers) that Tco is less
> than Troute, and can violate Tsu/Th ?
>
> Maybe a longer shifter literally takes more room, so statistically
> has more chance of long/short routes in the wrong combination ?
>
> If you run post route sim, does that flag any issues
> - ideally it should, right
>
> -jg


debug on top 4 bits, shift register 64 or 28 bits
"near ideal" external clock and shift data 4mhz down to 500khz
ProAsic3 FPGA

empty FPGA no matter synthesis settings - works correctly
full FPGA, 64 bits never worked unless forced global net
28 bits worked one P&R pass, not repeatable

surprising was that pattern 1001 did change to 1011 when the
issue was dominant in both cases of 28 and 64 lenghts! ?
and it was the same all P&R runs, and always the same 1011
also when the other logic changed a little.

to be honest i did expect that something simple as plain shift
register
will work properly (no matter what), that is the synthesis and P&R
tools
make the timings so that there are no violations.

another thing, the actel FPGA is REALLY full, the utilization varied
between 81-99%
so i was positivly surprised that actel tools never had any issues
with the implementation
no matter how full the FPGA was. even in runs where only 3 cells was
free!

but nothing comes for free - the internal skew on non global net, was
a hard hit in terms
of wasted time.

as there is no other explanation as net skew, and forcing global
buffer fixed the issue i
assume that that was it.

the only simulations I did run i did run with xilinx ISIM on the
design used as starting point
for the actel port, and on the xilinx back-ported version. I was about
to try post sims on
with actel timings, but as usual modelsim didnt want to start so i did
not get that far.
actel tools did not give any timing red alerts or anything

Antti

Reply With Quote
  #22 (permalink)  
Old 10-19-2007, 07:17 AM
Thomas Stanka
Guest
 
Posts: n/a
Default Re: FPGA quiz3, or where Antti did give up and does not know answer or acceptable workaround

On 18 Okt., 09:49, Antti <[email protected]> wrote:
> the failing desing was made with S 8.8A1 and was not tested with other
> version of synthesis tools
>
> after my quiz1 issue, that looked like tool error or faulty FPGA, I
> was not to belive that another problem so close the first one is
> related to tools making a mess, so I was very hard trying to find
> problem in my design.
>
> I have made backup of the "known failing with 8.8" design, when i have
> time, i will retest it with 8.6.2


Which technology are you using?
Do you read the Actel customer notifications?
"FSM Bug - Synplify® 8.6.2H in Libero® IDE 7.3, 7.3 SP1, and 7.3 SP2"
This notification states also that you need to use 8.8A2 instead of
8.8A1 for Axcelerator design due to another bug.

bye Thomas

Reply With Quote
  #23 (permalink)  
Old 10-20-2007, 06:33 PM
Antti
Guest
 
Posts: n/a
Default Re: FPGA quiz3, or where Antti did give up and does not know answer or acceptable workaround

On 19 Okt., 07:17, Thomas Stanka <[email protected]>
wrote:
> On 18 Okt., 09:49, Antti <[email protected]> wrote:
>
> > the failing desing was made with S 8.8A1 and was not tested with other
> > version of synthesis tools

>
> > after my quiz1 issue, that looked like tool error or faulty FPGA, I
> > was not to belive that another problem so close the first one is
> > related to tools making a mess, so I was very hard trying to find
> > problem in my design.

>
> > I have made backup of the "known failing with 8.8" design, when i have
> > time, i will retest it with 8.6.2

>
> Which technology are you using?
> Do you read the Actel customer notifications?
> "FSM Bug - Synplify® 8.6.2H in Libero® IDE 7.3, 7.3 SP1, and 7.3 SP2"
> This notification states also that you need to use 8.8A2 instead of
> 8.8A1 for Axcelerator design due to another bug.
>
> bye Thomas


PA3
it really looks like was caused by "fabric internal clock skew"
i use Xilinx AR and errata and well guess no also need read Actel PCNs
etc.
so 8.8A1 vs 8.9 didnt make a difference only manuall inserting CLK_INT
did.

I did no (too late but still) run post-layour simulations, and so far
did not see
the problem in those simulations. did not do yet enough sims to say
for sure
it will not ever show in simulation, just the few P&R runs did not
show it.

this single desing that caused the quiz1,2,3 issues is now finally
passed all
the issues and soon to be verified in full function. and I have some
more hard
lessons

Antti




Reply With Quote
  #24 (permalink)  
Old 10-24-2007, 12:08 PM
Nial Stewart
Guest
 
Posts: n/a
Default Re: FPGA quiz3, or where Antti did give up and does not know answer or acceptable workaround

> another thing, the actel FPGA is REALLY full, the utilization varied
> between 81-99%
> so i was positivly surprised that actel tools never had any issues
> with the implementation
> no matter how full the FPGA was.



Antti,

I've only skimmed this thread, but from what you've said the tools
_did_ have a problem with the implrmentation, they just didn't
know/report it.

I'd rather have had the tool tell me it couldn't P&R the design
than have to spend days debugging the faulty output.



Nial.


Reply With Quote
  #25 (permalink)  
Old 10-24-2007, 12:30 PM
Antti
Guest
 
Posts: n/a
Default Re: FPGA quiz3, or where Antti did give up and does not know answer or acceptable workaround

On 24 Okt., 12:08, "Nial Stewart"
<nial*[email protected] > wrote:
> > another thing, the actel FPGA is REALLY full, the utilization varied
> > between 81-99%
> > so i was positivly surprised that actel tools never had any issues
> > with the implementation
> > no matter how full the FPGA was.

>
> Antti,
>
> I've only skimmed this thread, but from what you've said the tools
> _did_ have a problem with the implrmentation, they just didn't
> know/report it.
>
> I'd rather have had the tool tell me it couldn't P&R the design
> than have to spend days debugging the faulty output.
>
> Nial.


Hi Nial,

well I also would have assumed that if the tools detect internal clock
routing skew beyond where the FPGA defenetly will not operate they
should report it, and not allow this P&R. Also the post-layout
simulation did not show problems. well not with the shift register
case. this same thing re-appeared in other part of the logic, where
post-layout simulation also did show error.

eh, just a hard-lesson (over 5 days of total struggle): for actel -
dont belive even post-layout sim, force all signal that clock any FF
to global nets.

actel cell has limitation on connections so i tried to trick to save
resources, and falled into a trap

Antti












Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
At what frequencies is it acceptable to generate a clock from a register? [email protected] FPGA 9 08-24-2007 11:00 PM
TFP410 acceptable video input timings (trying to run 1280x1024 at 60Hz with clock slower than 108 MHz) wallge FPGA 2 04-07-2007 12:18 AM
How much time margin should I give to a SDRAM interface via FPGA? news reader FPGA 3 04-02-2007 06:23 PM
Newbie : Please give me an idea about programming an FPGA [email protected] FPGA 7 10-18-2006 08:15 AM
Antti's last comp.arch.fpga posting Antti Lukats FPGA 9 08-25-2005 12:01 AM


All times are GMT +1. The time now is 06:16 AM.


Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved