forward error correction on ADSP21020

he

at

that snippet seems to imply that the UART is running at a clk that is equal to the baudrate, not some multiple of it (8 or 16 in most uarts)

If so I am surprised it works at all for any input

apart from the issues of metastability and such when sampling an async signal it shouldn't be a problem as long as the clock is some multiple of the baudrate, if you don't see the edge this clk cycle you will see it the next

-Lasse

On 3/8/2012 8:24 PM, snipped-for-privacy@fonz.dk wrote: [...]

The clk signal is 16 times the baudrate - my apologies if I did not explicitly stated that. The clk signal in the snippet is running at ~3.5 us, while the bit length is ~52us.

I think I was wrong here, the problem is on setup rather than hold time.

The problem is all about time violation. If you don't see the edge on the correct clk cycle you will never see it unless you have yet another edge. I'll try to argument it more to avoid - hopefully - further confusion: __ __ __ __ __ __ __ __ __ __ clk __| |__| |__| |__| |__| |__| |__| |__| |__| |__| |__| ________ ______________________ input |_______________________________| ______________ __________________ input_d |_____________________________| _____ cond ________| |________________________________________________ _____ start ______________| |__________________________________________

where cond = not input and input_d.

Since 'input' is not clocked with 'clk', you can see how the time that 'cond' is high depend on the phase between 'clk' and the input transition. In the event where input is happening *just before* the clk rising edge, input_d can toggle, but cond will not be long enough to ensure correct setup time for the start bit to start: __ __ __ __ __ __ __ __ __ __ clk __| |__| |__| |__| |__| |__| |__| |__| |__| |__| |__| ________ ______________________ input |_______________________________| _________ _____________________ input_d |_______________________________| _ cond ________| |____________________________________________________

start _______________________________________________________________

The hold time for 'start' is guaranteed by the place&route, since the tool will guarantee that delay between the 'input_d' and 'start' ffs are within a clock cycle. But the tool cannot guarantee that input is removed before the necessary setup time.

The correct design should have resynchronized the input with the internal clock (clk) and everything would have been fine, since from that moment on everything is running at the pace of the internal clock.

Hope that helps.

Something that should be done for _every_ input to the FPGA. Have you checked how other inputs are handled? If there is a problem like this on the UART data input, it is more likely that there is a problem with other inputs as well. Re-timing an input can in some cases also make it easier to meet timing requirements, maybe solving some of the timing errors you found when you tried to re-compile the FPGA?

I am not an expert on this, so if you want to go deeper into this, comp.arch.fpga may be a more suitable place.

In my opinion, based only on what I've read here (and I have not read every post in detail), you should go through the entire FPGA code and get it cleanly through the tools before you send it somewhere where it can never be changed again.

On 3/9/2012 9:51 AM, Stef wrote: [...]

Actually we have found tons of warnings for 'inferred latch' and stuff like that, when we tried to synthesize again the vhdl. I was staring with squared eyes when I looked at the logs. Unfortunately those guys did not have any idea of what they were doing and problems like the one in this thread are nearly everywhere in the FPGAs (likely there are only three in the system!).

thanks for the pointer, I am a very frequent reader of c.a.f.

We are going through the FPGAs every day, trying to understand the logic behind and the potential flaws. Sometime it is so poorly segmented that is very hard to understand the original intention.

Unfortunately everything is up in space now and we have to live with it. Given the level of the design I expect a lot of other big flaws somewhere else. We can only hope all these flaws can be circumvented by software, but it's a real pain.

That's what I initially understood from your posts. But later I somehow understood that the gear was still on the ground a was going into space. That made me wonder why you where working around the problem instead of solving the actual cause. Understood now (again): FPGA is fixed, no changes possible, ever.

Given the situation as it is, it is all you can do. Good luck!