1. Home
  2. Field-Programmable Gate Arrays
  3. fitting problem on A54SX72A

fitting problem on A54SX72A

Hi everyone, I have a strange behaviour in my implementation even if the design is pretty simple (even if it's very dense!). I have a decoding block which gets "address" to write data into several registers. The decoding block is such that it will produce an enable signal for each single register. Then a "write" signal is distributed with some latency such that propagation delays are taken into account. What I find is that for postsynthesis simulation everything is fine, but in my postlayout I have some addresses which are enabled even if the address is another one, turning out that I write two registers at once. I can't really understand why!

Here is a sketch of my vhdl code:

-- decoding signals > p_signal1 '0'; > p_signal2 '0'; > > > -- writing process > > process (clk, nrst) > begin > if nrst = '0' then > signal1 signal2 elsif rising_edge (clk) then > if wr = '1' then > if p_signal1 = '1' then > signal1 elsif p_signal2 = '1' then > signal2 ... > end process;

So it happens that writing to addr = x"123" it will change signal2 as well...how can it be possible???

I did prefer to have "p_signals" and not use directly the "addr" in the process just because in the very beginning I thought about latching the "p_signals" to have them stable, but then I realized it wouldn't have fit in the logic (I have already an occupancy of 84% and I have more than 300 addresses to decode). Do you have any explanation of this behaviour?

Thanks a lot for any comment

Al

--
Alessandro Basili
CERN, PH/UGC
Hardware Designer
Reply to
Al
Loading thread data ...

Maybe addr is not synchronized to clk.

-- Mike Treseler

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

--
Alessandro Basili
CERN, PH/UGC
Hardware Designer
Reply to
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

--
Alessandro Basili
CERN, PH/UGC
Hardware Designer
Reply to
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.

Reply to
Alvin Andries

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.

--
Alessandro Basili
CERN, PH/UGC
Hardware Designer
Reply to
Al

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

Reply to
Alvin Andries

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.