problem with xc3s400 place and rout section

hi i have a custom designed board with xilinx spartan 3( xc3s400 ) with two ethernet phy layer (RTL8201) for a two port switch. I have a ring network of 10 of this board on the chain. i transmit data from the first board and count the number of packets from the last ethernet port of the tenth board to test the integrity of switch and the hdl code.

the code in some synthesis work without error but when i add another piece of code for example a counter which is unrelated to the other logics and re synthesis the code the previous parts of my code work with error.

i guess it is due to place and route section and timing constranits of ethernet phy layer. this phy layer has 2 independ transmit and receive clk and due to ease of pcb routing i connected these clk signals to normal pins not the global clk pins and now i think the timing constraints are disabled since i used this contraint on the pin NET "RTL_RXCLK" CLOCK_DEDICATED_ROUTE = "FALSE";

in timing reports it is said that all timing constraints are met but there is warning saying ?The use of

this override is highly discouraged as it may lead to very poor timing results? . what is the problem and

how can i fixed the problem ?i cannot change the pcb because of the price and time :( is it possible to check and apply timing constraints in fpga editor?

Tnx in advanced for any helpful comment Neda Baheri

--------------------------------------- Posted through

formatting link

Reply to
nba83
Loading thread data ...

The CLOCK_DEDICATED_ROUTE constraint will not disable timing analysis. It is only a routing directive. If you have timing constraints that cover the period, clock to output, setup and hold for this clock, then you should still be able to see if there are timing issues after static timing analysis.

I generally recommend generating a verbose timing report with "report unconstrained paths" set to a large number like 100. This might show areas that need additional constraints.

On the other hand, there is still the possibility that this design has errors in clock crossing logic or asynchronous signal synchronization. That sort of problem very often comes and goes with a new build due to changes in placement, and therefore changes in relative routing delays of the poorly handled signals.

--
Gabor
Reply to
GaborSzakacs

two

network

and

board

piece

re

clk

pins

disabled

there

price

fpga

Tnx for your helpful comment. I have 6 clock signals: 2 tx_clk(25MHz), 2 rx_clk(25MHz) for 2 Phy layers, 1 for adc sampling(1MHz) , 1 for spi(1MHz) communication. I only have period constraint for 25MHz clk signal. I don't have any idea how to set clock to output, setup and hold constraints for these clocks. and for 1MHz clocks there is no time constraint (since these clocks are so slow to set any constraints).

how should I know from verbose timing report that which areas need additional constraints? and how should I apply the changes to my design?

I hardly think there must be cross clocking domain issues, I have buffers to receive data from RX clock and transmit from TX clock.

Tnx in advanced for any helpful comment Neda Baheri

--------------------------------------- Posted through

formatting link

Reply to
nba83

The ISE GUI has a utility under the process: User Constraints --> Create Timing Constraints that helps you build timing constraints for the design.

As for finding the additional constraints you need, you can look at the Static Timing from the Design Summary viewer. You will see lots of entries in the report starting with the word "Unconstrained." Look at the reported worst case paths for these to see if they violate your system requirements.

At 1 MHz or even 25 MHz, you're not likely to see issues with PERIOD timing. However there is always the possibility of input setup and hold or clock to output timing issues, especially if you haven't pushed all registers into the IOB's.

You also state "I hardly think there must be cross clocking domain issues..."

I would suggest you think again. Wherever you use a signal in a synchronous process that was not sourced by the same clock, you can have a clock-domain-crossing (CDC) issue. In state machines these can lead to lock-up, or to occasional wrong behavior. The lower your operating frequency, the less often the failure occurs, but there is no frequency above DC where it can't happen, because it has to do with setup and hold time, and not signal delay. The standard tools you get with ISE do not check for CDC issues, and you'd have to spend a lot of money to get a tool that automates this process. However, if you know your design you can go through it and check for areas of potential problem. The number one rule for CDC is that any signal must go through exactly one flip-flop where it crosses into a new clock domain. i.e. the same signal must not be sampled by two different flip-flops in the new clock domain. After going through the first flop, the Q of that flop can be sampled by multiple other flops in the new domain. If you are concerned about metastability, you can add a second flop after the first one before fanning out. i.e. consider the output of the first flop in the new domain to still be "asynchronous" because it can have unknown additional metastable delay.

You can probably get a lot more information about CDC if you google for "Clock Domain Crossing." There are also a lot of discussions on this topic in the Xilinx user forums at:

formatting link

--
Gabor
Reply to
GaborSzakacs

(snip)

(snip)

Note that there are two problems to worry about in clock domain cases. One is metastability, where one signal changes at just the wrong time.

The second comes when multiple signals are latched by the same clock, such that some might change before, and others after, the clock edge. This is unrelated to metastability, and would happen even with zero setup and zero hold time.

One favorite case is passing a count value from one side of a FIFO to the other. Note that with different delays, the different bits of the counter might get latched on different clock edges. That would result in the value latched being nowhere near the desired value.

If you can't be sure that it won't happen, the system has to work with the bits, no matter which side of the clock edge they are on. In the FIFO case, the fix is a gray-code counter. In gray code, only one bit changes at each transition, so that the other side gets either the new or old value, never any other.

-- glen

Reply to
glen herrmannsfeldt

It doesn't have to be multiple bits. It can be one bit going to multiple destinations.

I had a UART in a test fixture design and was having all sorts of problems with it. In debugging it was hard to capture the fault and I spent a lot of time on this thinking it was a software problem. Eventually I found that I had made the rookie mistake of omitting the sync FF on the data input. That signal was feeding the shift register, the state machine and the error detection logic. It would sometimes change at the right time so that the old bit was seen by part of the state machine and the new bit was seen by other parts so that it would corrupt the function and therefor the data.

ALWAYS sync incoming data through one FF and if you have any worries about meta stability sync through two FFs. Further, your clocks likely can be combined (other than the xmit and rcv clocks). 1 MHz SPI and ADC sampling can be derived from a 25 MHz clock. Pick one clock you will have around at all times and use that as the "master clock". When transferring data between domains, use that clock as the clock of reference.

Even easier is to use say a 100 MHz clock as the master clock and bring

*all* data into that domain immediately and performing all processing in that domain before passing it to a different output clock domain.
--

Rick
Reply to
rickman

(snip, I wrote)

(snip of FIFO example)

Yes. Well, depending on how you look at it, that is multiple bits.

If you can draw a line through the schematic, and it crosses multiple lines that come from one clock (including outside signals with unrelated clocks) and going to separate FFs, that is the same as multiple bits.

But I agree that it is less obvious when thinking about it, compared to bits output from a counter.

UART reminds me, I knew someone interfacing an 8251 UART to an Apple II, including connecting data lines D0 through D7 to D0 through D7. Unfortunately, the two didn't number the bits the same way.

-- glen

Reply to
glen herrmannsfeldt

Are you aware that you can add wires to a PCB? If you are only talking about 10 boards then it would not be too hard a task to add a few wires. If you are talking about 1000 boards you should redo the board.

Also, the problem created by not routing the clock into the chip on a clock pin only has to do with the timing of the I/O signals relative to the clock. Bringing the clock into the chip on a non-clock pin means the clock must be routed through the general routing with a larger variation in timing. So if you have 5 ns of setup time on your data, but run the clock on a non-dedicated clock pin your setup time at the FF may be close to 0 or even negative meaning a timing violation.

--

Rick
Reply to
rickman

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.