We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for
Did you mean:
Explorer
8,764 Views
Registered: ‎06-28-2008

## What will happen if pull up resistor of DONE pin is incorrect ?

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 ???

17 Replies
Teacher
8,761 Views
Registered: ‎07-21-2009

## Re: What will happen if pull up resistor of DONE pin is incorrect ?

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

SIGNATURE:

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
Explorer
8,752 Views
Registered: ‎06-28-2008

## Re: What will happen if pull up resistor of DONE pin is incorrect ?

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.

Teacher
8,747 Views
Registered: ‎07-21-2009

## The DONE pullup R is NOT the problem.

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

SIGNATURE:

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
Instructor
8,744 Views
Registered: ‎08-14-2007

## Re: What will happen if pull up resistor of DONE pin is incorrect ?

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

-- Gabor
Explorer
8,715 Views
Registered: ‎06-28-2008

## Re: The DONE pullup R is NOT the problem.

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???

Teacher
8,704 Views
Registered: ‎09-09-2010

## Re: The DONE pullup R is NOT the problem.

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

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

www.edn.com/file/17561-310388.pdf

------------------------------------------
"If it don't work in simulation, it won't work on the board."
Teacher
8,704 Views
Registered: ‎07-21-2009

## Re: The DONE pullup R is NOT the problem.

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

SIGNATURE:

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
Explorer
8,684 Views
Registered: ‎06-28-2008

## Re: The DONE pullup R is NOT the problem.

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 ?

Teacher
8,678 Views
Registered: ‎07-21-2009

## On what planet is this OK?

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

SIGNATURE:

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
Teacher
6,455 Views
Registered: ‎07-21-2009

## clock domain crossing through dual-port RAM

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

SIGNATURE:

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
Teacher
6,452 Views
Registered: ‎09-09-2010

## Re: On what planet is this OK?

"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.

------------------------------------------
"If it don't work in simulation, it won't work on the board."
Instructor
6,450 Views
Registered: ‎08-14-2007

## Re: On what planet is this OK?

@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

-- Gabor
Explorer
6,433 Views
Registered: ‎06-28-2008

## Re: On what planet is this OK?

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 ???

Teacher
6,430 Views
Registered: ‎07-21-2009

## Debugging EMIF interface?

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

SIGNATURE:

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
Explorer
6,420 Views
Registered: ‎06-28-2008

## Re: Debugging EMIF interface?

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

Teacher
6,417 Views
Registered: ‎07-21-2009

## Re: Debugging EMIF interface?

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

SIGNATURE:

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
Explorer
6,407 Views
Registered: ‎06-28-2008

## Re: Debugging EMIF interface?

Well ,  I will post a new thread later.