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=3D'1') then do64(62 downto 0)

Reply to
Antti
Loading thread data ...

Antti,

Could you fix the typo > Hi ho

Reply to
Dave

nden -

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=3D'1') then do64(63 downto 0)

Reply to
Antti

Reply to
Mark McDougall

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, 
 Click to see the full signature
Reply to
Mark McDougall

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 to
Antti

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 to
neilla

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 to
Kim Enkovaara

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 to
Antti

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 to
Antti

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 to
Jim Granville

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 to
Antti

lenden -

Reply to
Marc Randolph

t I

sblenden -

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 to
Antti

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 to
Brian Davis

yes me stupid already fix

Antti

Reply to
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

formatting link

Reply to
John McCaskill

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 to
Antti

t I

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 to
Antti

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 to
Jim Granville

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.