General Technical Discussion

[eteam00]

And my logic can assure that the read and write do not occur  at the same time.

If you guarantee that read and write do not collide, then you have no problems.  If you are able to avoid such collisions, then you can probably do without the dual port ram (and just use a register).  It's not the dual-port ram which provides safe clock domain crossings.  In a proper FIFO, it's the asynchronous FIFO logic (and not the dual-port ram) which provides this capability.

In any case, you should add comments to your code that avoiding read/write collisions is critical to the design, and thoroughly test the logic which implements this protection.

-- Bob Elkind

[rcingham]

"You are comparing a 34-bit register to 33-bit signal and register? Yes！"

An advantage of VHDL over Verilog in this sort of situation is that VHDL will always give a clear and unambiguous answer: a 34-bit signal NEVER equals a 33-bit signal. This forces the designer to be clear in their intentions.

[gszakacs]

---

rcingham wrote:
"You are comparing a 34-bit register to 33-bit signal and register? Yes！"

An advantage of VHDL over Verilog in this sort of situation is that VHDL will always give a clear and unambiguous answer: a 34-bit signal NEVER equals a 33-bit signal. This forces the designer to be clear in their intentions.

---

The Verilog LRM makes it quite clear what happens when dealing with arguments of different

sizes.  The smaller argument is extended with zeros unless all arguments are signed, and then

the smaller argument gets sign-extended.  While this behavior doesn't always make sense

(especially when comparing a smaller signed argument with a larger unsigned one), it is

not up to the synthesizer to decide how to do the comparison.  There is a right way to do it

by the LRM.  So in that regards, Verilog is no less clear than VHDL.

On the subject of dual port memory and clock crossings, the statement that when there is

a collision, the read data will be the older one because the RAM is read first only works

if the read and write clocks are the same.  If the collision occurs at some random

timing offset between write and read, there will be cases where the read data will

not be stable at the read clock edge.  This is no different than using a simple register

for CDC.  You need to make sure that read and write pointers into the RAM don't

collide in order to have a clean clock crossing.  If you don't understand how to do this,

then the best way is to use a FIFO from CoreGen.

-- Gabor

[jlqsczw_2007]

simple dual-port RAM IP core----

I only wrrte six data in RAM ,wait for a while and read them every 1ms.

port A , a local DCM output whose input is a external EMIF_CLK,   100M

write enable and write addr are from DSP, asynchronous to FPGA

port B , an internal clock from another DCM, also 100M,

read enable is always valid,

read addr is generated using this clock

I  used chipscope to find the bug.

In most cases,all things are right.

The "write" should be right without considering the timing , at least the write enable and write data are there all the time.

Sometimes five data read from RAM are right ,but one is zero.

(The read logic is the same)

Sometimes all six data read from RAM are zero.

Now there are no error in the timing report.

I guess it's the setup or hold time of write or read that  does not meet the requirement.

But I do NOT know how to determine which one contribute to the bug ,write timing error， read timing error or CDC error ??? setup or hold timing ?

What I can do is only slow down the read or write speed.

Or add OFFSET constraints,  write enable , write addr, write data regarding write clock,   read addr regarding read clock ???

[eteam00]

Have we moved from DONE pin not going HIGH to coding style to clock domain crossing to debugging a DSP EMIF interface?

If so, then you should post links to the DSP datasheet (showing the EMIF interface signals and waveforms), and your FPGA code for the DSP interface.

You should also post the board-level schematic showing DSP <==> FPGA connections.

If the problem is consistent, the problem is likely a logic problem.

If the problem is inconsistent, the problem is likely due to a timing or signal integrity issue -- which may involve board design, DSP coding and configuration, and FPGA logic design.

-- Bob Elkind

[jlqsczw_2007]

Have we moved from DONE pin not going HIGH to coding style to clock domain crossing to debugging a DSP EMIF interface?

---Yes. Now the resistor thing seems not to be the issue.

If so, then you should post links to the DSP datasheet (showing the EMIF interface signals and waveforms), and your FPGA code for the DSP interface.

You should also post the board-level schematic showing DSP <==> FPGA connections.

---- I have no shematic in my hand ,but the signals between DSP and FPGA are all connected directly,no other chips.

If the problem is consistent, the problem is likely a logic problem.

If the problem is inconsistent, the problem is likely due to a timing or signal integrity issue -- which may involve board design, DSP coding and configuration, and FPGA logic design.

-----Obviously the problem is inconsistent.

If it's timng ,now no timing errors are reported , so I can only decrease the speed of writing.

If it' signal integrity , now I have no ideas.

-- Bob Elkind

[eteam00]

j,

Please try to simplify and clarify and separate the various questions you have.  It does not help to have a single thread wandering between a variety of discussion topics.

You have already started a thread for debugging your EMIF interface, which is yet unresolved.  Suggest you clarify the EMIF interface questions and problems in that thread, and post both your board-level schematics and your latest version of EMIF interface source code.

For the remaining questions or topics, please list and describe them separately in this thread.

-- Bob Elkind

[jlqsczw_2007]

Well ,  I will post a new thread later.