Hi,

We have been evaluating OR1200 in FPGA and everything seems to work well. So we moved on to use Synopsys design compiler and we see timing loop. I attached the timing loop report to this topic. Has anyone seen this problem? I guess this is not a functional loop since everything seems to work in FPGA.
Problem is our backend design team will not accept any design with timing loop. So we need to resolve this if we are going to use it actual design. Is there updated RTL that resolve this issue?

Thanks in advance

Unfortunately, it is a bit hard to tell if there is updated RTL unless you state which SVN revision or release you are using, and whether it's the original or1200 code or the one in ORPSoC

We have been evaluating OR1200 in FPGA and everything seems to work well. So we moved on to use Synopsys design compiler and we see timing loop. I attached the timing loop report to this topic. Has anyone seen this problem? I guess this is not a functional loop since everything seems to work in FPGA.
Problem is our backend design team will not accept any design with timing loop. So we need to resolve this if we are going to use it actual design. Is there updated RTL that resolve this issue?

Thanks in advance

---------------------------------------------------------

I ran the code through an rtl checker a few years ago and I remember seeing a loop. This is probably the same one. I don't think it is a functional loop since it is up in the instruction cache and quick mem area. But you will still need to insert some break logic into it. Break logic is a mux that passes the signal through in mission mode but runs it through a flop in scan_test. This will make the backend team happy.

The problem is that the loop doesn't care where you insert the break logic but you have to be careful that you don't also break some valid timing arc that happens to pass through the loop. Tracking these down can be time consuming and requires a detailed understanding of the logic. I never bothered to spend that much time.

If you do then please post your findings so that we can fix it

John Eaton

I followed the signal for a while, and I would guess qmem is the issue here. Is qmem enabled (OR1200_QMEM_IMPLEMENTED is defined), and if it is enabled, what RAM implementation are you using?

QMEM is enabled. We instantiated a memory around 8KBytes using one of our existing ASIC memory. Just as experiment, we removed the QMEM implementation and timing loop is no longer there. We haven't tried this with FPGA, so not sure what will be the consequence of not using QMEM. Does anyone know what QMEM is for and how it will effect over all performance of CPU if excluded from design?

Thanks
Daniel

QMEM is like ARM's TCM. It is a directly attached memory, so the CPU can access it without going through the cache and memory subsystem, which avoids memory access hazards and stalls. Use it to store critical interrupt routines and frequently accessed memory blocks (the stack for example).

Richard

I'm not very familiar with the design of the existing qmem implementations, but if it's possible, I would propose that you add a register stage to the perimeter of your QMEM implementation. Perhaps the other implementations already has that

On a quick glance, QMEM in itself is not the problem. The loop probably has something to do with instruction cache inhibit signal, which is affected through iaddr_qmem_hit with the qmem address, which itself is affected by either icpu_rty or icpu_ci signals.

There shouldn't be any problems if you either just use Wishbone (and completely disable QMEM) or vice-versa (in this case, the iaddr_qmem_hit probably gets optimized away). iaddr_qmem_hit is used as a select for some muxes in or1200_qmem_top.

I think you could make qmemimmu_ci (cache inhibit signal in or1200_qmem_top) a constant and avoid this problem, but at this time I cannot test this.

It turns out we are not using QMEM even though we implemented it. The default address mask for those *_hit* signals are 0x80_0000 which is beyond our max memory range. So we commented out QMEM implementation and everything seems to work. We don't really want to change RTL since we don't have detail testbench to verify everything. Hopefully, someone with more detail knowledge of design can fix this problem in the future.