fitting problem on A54SX72A

Maybe addr is not synchronized to clk.

-- Mike Treseler

unfortunately it is synchronized with clk and so it is the wr signal. The Designer shows a lot of timing problems but with multicycle path i managed to solve those problems (even if those constraints are not used to optimize the path, only to check timing constraints). I tried to synchronize even the p_signal (getting to the 98% of occupancy) but it didn't help. I'm still puzzled!

Al

I've decided not to wait longer and program the chip regardless of the simulation problem. I found that the chip shows no such problems in the registers but I should test it within the temperature range and see if it will work correctly. I still don't know why the simulation doesn't end correctly.

By the way, some collegues of mine told me that Sinplify implements two registers when these are read/write registers and one is used for read and both are used for write. This is due to the fact that the second register may be internally used for some other logic which will need to access to this register. Is it possible? Will this behaviour lead to the problem I described in this thread?

Thanks all,

Al

Hi Alessandro,

What do you mean with postsynthesis and postlayout? Gatelevel with and without timing?

Also, what did you do with your write signal? Normally, you wouldn't have to delay it in a synchronous environment.

Your code seems ok, even though I would replace the elsif p_signal2 by regular ifs: the reason is that you're now describing a priority decoded block, whik this is unnescessary.

Regards, Alvin.

Well, the postlayout is gatelevel with timing of logic elements but not the routes (I think there's just an estimation of which will be the route and timing is computing based on this estimation). Postlayout is considering the actual routes after place&route process and all delays are taken into account. Moreover I had to implement a simulation considering the INDUSTRIAL ranges in temperature and voltage to take into account timing changing according to these two parameters.

Unfortunately the p_signals are really many, in the order of 300 and, for the Actel chip I'm using, there's a long delay introduced in the decode chain of all this combinatorial logic. That's why, to overcome this, I needed to add some latency in the write signal which will allow me to have the data stable and the p_signal stable when the write signal arrives.

I agree with you, even if I thought that the if elsif structure would have been much simpler to write, otherwise I have to implement a process for any register, turning out with a less readable code. But I will try with a case when structure and try to see if there are any differences in the implementation.

By the way I did registered the p_signal, fearing that the synthesizer would have put the write signal at the very beginning of the chain instead at the end, but the simulation didn't work either.

Comments in the text.

have to

This is wrong. Normally you specify your I/O timing and clock constraints and the synthesis tool should tell you if it met those or not. Combinatorial delay will be optimized away anyway.

Currently, each of the "p_signal