General Technical Discussion

[jlqsczw_2007]

Virtex 5 SXT 240T

BPI flash: xcf128X

Let's look at the graph.

If the pull up resistor of DONE  is NOT 330 ohm BUT 4.7kohm,

what will happen?

Because  we have met some weird things------ a simple circuit, which only generate a  waveform with fixed period and width ,  will change the width occasionally.I doubt that maybe the resistor cause the problem.

What's more ,the value of two resistors of CCLK is not given in the graph , is it also 330 ohm ???

[eteam00]

If the pull up resistor of DONE  is NOT 330 ohm BUT 4.7kohm, what will happen?

I can imagine two possibilities:

1. The "HIGH" signal level on DONE may not be high enough to be recognised as a valid "DONE" signal.
2. If the DRIVEDONE option is set in BitGen, then there should be no problem with a pullup R value which is too high (or missing).

These are guesses, and are based on your diagram showing single-device MASTER configuration mode.

Because  we have met some weird things------ a simple circuit, which only generate a  waveform with fixed period and width,  will change the width occasionally. I doubt that maybe the resistor cause the problem.

Agreed.  The DONE pin pullup is not likely to be the cause for such behaviour.

What's more, the value of two resistors of CCLK is not given in the graph, is it also 330 ohm ???

The two resistors are intended to be parallel termination, with an equivalent impedance of 50 ohms.  In Xilinx docs, these two Rs are each 100 ohms.  See UG191, Figure 2-25.

-- Bob Elkind

[jlqsczw_2007]

1)

• The "HIGH" signal level on DONE may not be high enough to be recognised as a valid "DONE" signal.

Will the "not high enough" cause FPGA does not work correctly , or some logic is correct another is wrong ???

2)

My logic is

input [32:0] a;

parameter WIDTH = 32'd 10000;

reg[32:0] b;

always @(posedge clk)

...

b <= a + WIDTH;

reg[33:0] counter;

always @(posedge clk)

...

if ((counter > a) && (counter < b))

gate <= 1'b1;

else

gate <= 1'b0;

The "a" signal is written by DSP. We use dual -port RAM to ensure "a" is written reliably without CDC problem.And we use chipscope to watch it to prove it.

Most of the time the "gate" signal is correct,

but occasionally the width of "gate"changed quickly,small,big,small,... back and forth.

The clk is local clock.

The WIDTH is a fixed parameter.

Even if "a" is wrong when writing , WIDTH should always be correct so the width of "gate" should be fixed.

I am really confused.

[eteam00]

Will the "not high enough" cause FPGA does not work correctly?

No, this would cause the FPGA to not work at all.

input [32:0] a;

'a' is a 33-bit input?

parameter WIDTH = 32'd 10000;

reg[32:0] b;

'b' is a 33-bit register?

always @(posedge clk)

...

b <= a + WIDTH;

You are adding a 32-bit value to a 33-bit signal?

reg[33:0] counter;

counter is a 34-bit register?

always @(posedge clk)

...

if ((counter > a) && (counter < b))

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

gate <= 1'b1;

else gate <= 1'b0;

'a' is an asynchronous input, correct?

• What might happen to 'b' if 'a' is changing just before register 'b' is being clocked?
• What might happen to 'gate' if 'a' is changing just before register 'gate' is being clocked?
• What might happen to 'gate' if 'b' is corrupted by async timing of 'a' input?

The "a" signal is written by DSP. We use dual -port RAM to ensure "a" is written reliably without CDC problem.And we use chipscope to watch it to prove it.

A dual-port RAM, by itself, does not guarantee safe clock domain crossing.  A proper FIFO would suffice for clock domain crossing, but a bare dual-port RAM remains sensitive to setup/hold time violations.  Chipscope is not a reliable verification tool for timing or clock domain crossing problems.

Are you still confused?

-- Bob Elkind

[gszakacs]

The DONE pin has nothing to do with your problem.  It can only prevent the FPGA from starting up

at the end of configuration.  It will not affect the behavior of the design once the FPGA starts up.

On Virtex 5, I have noticed an issue where configuration startup will not complete if DONE

is pulled up too weakly, or if the configuration clock is very fast (even with 330 Ohms).  This

problem can be avoided either by using the "drive DONE pin high" option as Bob noted,

or if you don't need DONE for another FPGA on board, then by using the "enable internal

DONE pipe" option.  The latter allows the FPGA to use its internal DONE signal for startup

and ignore the voltage on the DONE pin.  In any case, the only thing DONE can do to your

design is prevent it from running altogether.  It will not cause the issues you are seeing.

My first suspicion would be that you don't have adequate timing constraints to ensure that

your design runs at the clock frequency of the board.  You need to have at a minimum

a PERIOD constraint on your clock, plus OFFSET IN BEFORE constraints on the signals

driven by the DSP.

Is the value of "a" changing when you observe the wrong pulse width?  If so I would

expect that your design has issues with setup or hold to the clock.  If not, then I would

imagine that your 33-bit magitude comparitor is not meeting the clock period requirement.

-- Gabor

[jlqsczw_2007]

The internal resitor by ISE and the external one will be added together and make up a bigger one ??? Or one will override another? 

always @(posedge clk)

...

if ((counter > a) && (counter < b))

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

Yes！

gate <= 1'b1;

else gate <= 1'b0;

'a' is an asynchronous input, correct?

• What might happen to 'b' if 'a' is changing just before register 'b' is being clocked?
• What might happen to 'gate' if 'a' is changing just before register 'gate' is being clocked?
• What might happen to 'gate' if 'b' is corrupted by async timing of 'a' input?

---- FPGA gives DSP an interrupt whose period is 1ms.

Every 1ms , DSP will  write the dual port RAM of FPGA several data but at most  once.

And I read the data from dual port RAM just before the end of 1ms.

Then I update "a" and other signals using local clock.

After these procedures, a,b,gate are in the same clock domain.

A dual-port RAM, by itself, does not guarantee safe clock domain crossing.  A proper FIFO would suffice for clock domain crossing, but a bare dual-port RAM remains sensitive to setup/hold time violations.  Chipscope is not a reliable verification tool for timing or clock domain crossing problems.

----

Why dual-port RAM can not guarantee safe CDC??

I want to use FIFO but I was told that every 1ms the number of data written by DSP changes，maybe 3,or 5,or ...

Therefore I have nothing to do but use the address signal to decode the data.

Then I have to use dual-port RAM to deal with CDC.

I have no other ideas about that now.

You need to have at a minimum

a PERIOD constraint on your clock, plus OFFSET IN BEFORE constraints on the signals

driven by the DSP.

---

I have add PERIOD constraint but no OFFSET ones now.

Is the value of "a" changing when you observe the wrong pulse width?  If so I would

expect that your design has issues with setup or hold to the clock. 

----

I have seen the bug in oscilloscope but not in  chiscope because most time it does not often occur.

So I do not know if a is right at that time .

I will use chipscope to watch it in several days.

If not, then I would

imagine that your 33-bit magitude comparitor is not meeting the clock period requirement.

---

The timing report does not report any error on RAM or comparator.

Could it be said that the report is unreliable ???

Were it the reason, how to solve it???

[rcingham]

"Could it be said that the report is unreliable?"

If you have fully-correct Timing Constraints, the report is reliable.

I advise you to read:
www.edn.com/file/17561-310388.pdf

[eteam00]

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

Some possibilities:

• register bit [33] is ignored, and comparison is 33-bit rather than 34-bit
• 33-bit signal is extended to 34 bits by copying bit[32] to bit[33]
• 33-bit signal is extended to 34 bits by using '0' for bit[33]

Are all of these possible interpretations of your logic description equally acceptable?

Why dual-port RAM can not guarantee safe CDC??

What happens when you are reading the same memory location which is being written, with two different clock domains on the read and write ports?  Consider the following read/write port timing relationships:

• If the write occurs before the read, the newly-written data value will be read.
• If the write occurs after the read, the newly-written data value will not be read.
• Between the timing points described in the first two examples, there is some range of read/write timings where some (but not all) of the newly-written data values will be read correctly.

-- Bob Elkind

[jlqsczw_2007]

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

Some possibilities:

• register bit [33] is ignored, and comparison is 33-bit rather than 34-bit
• 33-bit signal is extended to 34 bits by copying bit[32] to bit[33]
• 33-bit signal is extended to 34 bits by using '0' for bit[33]

Are all of these possible interpretations of your logic description equally acceptable?

——

I simulated in ISIM which showed that 33-bit signal is extended to 34 bits by using '0' for bit[33].

In my opinion,the synthesis tool should give a fixed result, not three possible results.

Now the bug( changing "gate") occured when DSP wrote a fixed width.

Most time "gate" is right, but occasionally it is wrong.

Why dual-port RAM can not guarantee safe CDC??

What happens when you are reading the same memory location which is being written, with two different clock domains on the read and write ports?  Consider the following read/write port timing relationships:

• If the write occurs before the read, the newly-written data value will be read.
• If the write occurs after the read, the newly-written data value will not be read.
• Between the timing points described in the first two examples, there is some range of read/write timings where some (but not all) of the newly-written data values will be read correctly.

-------

The dual-port RAM is IP core -- Block memory generator AXI4 6.3 of Xilinx.

Port A is write only, write first mode, 

port B is read only, read first mode which means the the old value in RAM will be read first .

And my logic can assure that the read and write  do not occur

 at the same time.

Does it work ?

[eteam00]

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

Some possibilities:

• register bit [33] is ignored, and comparison is 33-bit rather than 34-bit
• 33-bit signal is extended to 34 bits by copying bit[32] to bit[33]
• 33-bit signal is extended to 34 bits by using '0' for bit[33]

Are all of these possible interpretations of your logic description equally acceptable?

I simulated in ISIM which showed that 33-bit signal is extended to 34 bits by using '0' for bit[33].

In my opinion,the synthesis tool should give a fixed result, not three possible results.

Well, thank goodness for your opinon!  Well, you are right, the synthesis tool should give a fixed result.  The problem is that you (or anyone else) may be unsure of which fixed result might be given, based simply on reviewing your source code.  And the chosen fixed result may not be a permanent, reliable, or universal choice.

Your opinion is just fine because...

• You should have to run ISIM to figure out the intention of your logic.
• The unwritten rules of the synthesiser will never change with some future update.
• No-one else will have to pick through your code because you will never leave the company or be hit by a bus.
• Someone writing DSP code to interface with your FPGA design will always guess the intended logic function correctly.
• ISIM will never use a different set of rules than ModelSim or Synplify or XST hardware synthesis, so ISIM is always right.
• You live on a planet where intentionally ambiguous source code is considered a good idea.

It's time to be honest with each other... engineer to engineer, designer to designer.  If your job and livelihood depended on the work of a colleague, would you choose

• a colleague who thinks ambiguous code does not need to be corrected
• a colleague who writes clear, unambigous code with clear meaning and intent, with descriptive comments, that you can easily and readily understand

Seriously... this is no laughing matter.  If you make a mistake, don't defend it .  The fact that you might be able to get away with this practice, in this instance, is not a basis for defending unclear, ambiguous, uncommented, undocumented source code.  It's not just your pride which is at stake.  Other people are depending on you, or they will be depending on you if you continue with design work.

Some risks and assumptions are unavoidable in design engineering.  Life is too short to knowingly add forseeable and avoidable risks to your work, much less defend such a sloppy attitude.

-- Bob Elkind