Forum Discussion
Altera_Forum
Honored Contributor
Honored ContributorHow to constraint my design using TimeQuest?
I am looking for some help to constrain my design. I've never done a timing constraint and my understanding of the subject isn't very deep at all.
An overview of my design: it consists of a 72 bit shift register which is loaded in parallel (so that's 72 inputs). This data, when requested, is sent out via SPI. The SPI interface consists of MISO, MOSI, SCK (2 MHz) and CS. I sync. the SCK and CS signals to a 20 MHz clock (CLK) and shift out the data on the falling edge of the synchronized SCK signal (i.e. SCK_falling). Similarly, the chip is only active the synced copy of CS goes low (CS_falling). When CS_rising is 1, I load the data into the 72 bit shift register. Now, my question is, how do I properly constrain this design so it works on a real design? From my limited understanding, it seems I need to first create two clocks (SCK and CLK). I note that TimeQuest asks for the rising and falling times of the signal. Do I simply measure this on my board and enter it? In my case, I actually remember this: the rising/falling time for SCK is just 7 ns. However, for CLK it's a bit more tricky. My o-scope is only 50 MHz and the 20 MHz waveform appears quite distorted so it will be hard to measure the rise/fall times - can I just leave them out? Secondly, do I need to constraint the 72 inputs? If so, how? What about CS, MISO and MOSI? None of these have a set frequency as CS can go low and high at any time. So how does one go about constraining these?34 Replies
Altera_Forum--- Quote Start --- You set SO as a false path just so TimeQuest won't complain. You ensure that you wait (at least) 1 clock cycle, not by setting constraints but by the working of your logic. In fact, you're already waiting 2 cycles (from the synchronizers) + 5 cycles (SCK falling) before changing tmp. I would just make SO depend on a synchronized/delayed version of nCS as well, to make sure SO doesn't go to Z too soon on the last bit. --- Quote End --- Ah I see. The last part should be trivial as I already have a synced version of nCS.- Altera_Forum
Random thoughts
a) I'd say there's no problem with SO. Even if you wait 7 cycles (350 ns), you still have 140 ns for the signal to get out of the FPGA, reach the MCU and meet it's setup requirement. But since you said you're using resistors to slow down the signal.. maybe it's so slow 140 ns aren't enough? b) For PI, you can try to be a bit more pessimistic on the min delay, using 7 or 8 ns instead of 10. Though, if it works at 500 kHz but not 20, it's unlikely to be a hold violation. - Altera_Forum
The resistors are 100 Ohms and the rising edges, after slowing down, are about 7 ns. So I don't think the signal is that slow.
As I mentioned, the other CPLD/FPGA (let's call this U1) n the design, has 72 outputs which connect to the 72 inputs of this CPLD (U2). We connect them together via a group of wires (these are actually the things the board tests by driving a test vector onto them). The U1 CPLD doesn't connect directly but instead drives 72 MOSFETs which in turn buffer the signals on the bunch of wires. To reduce ringing, I have a 1 K resistor at the gate and a 1 K pull-up as well (again, due to my inexperience, I didn't realize that I could control the ringing better via clamping diodes. A termination resistor wouldn't work well because the wires are not good transmission lines and their Zo varies. The next revision of the board will have clamping diodes instead of 1 K resistors to slow down the signal). The pull-up is located near to U2 so that it has a default value incase the wires are not connected. It could be that the 1K resistor + the length of the wire is causing the signal to appear a bit too late? However, I do sample PI at every rising edge of sys_clk, so I'm not sure. Will I need to increase the input delay for PI? - Altera_Forum
How many cycles go between U1 setting a new value on it's PO and U2 entering the mode where it samples PI?
And how many cycles will U1 keep PO stable after U2 has exited the PI sampling mode? - Altera_Forum
U2 samples PI whenever CS is high and there is a rising edge on sys_clk. So PI is being sampled quite often, whenever the CS isn't active.
U1 will keep PO stable until and unless a new command is given and CS is rises. The command isn't executed until and unless CS goes back high.process(CLK, nRESET) begin if (nRESET = '0') then tmp <= (others => '0'); elsif rising_edge(CLK) then if CS_sync = '0' then if SCK_falling = '1' then tmp <= tmp(PI'high -1 downto PI'low) & '0'; end if; elsif CS_sync = '1' then tmp <= PI; end if; end if; end process; SO <= tmp(PI'high) when nCS = '0' else 'Z';
What the MCU does is that it first sends the command "shiftVector" to U1. As soon as the transmission is done, the CS for U1 is brought high and the MCU begins lowering CS for U2 and starts receiving data. So the amount of cycles between when the vector is shifted and when data is received will depends on how fast the MCU is executing. This should be straight forward to measure, I have a 2-channel o-scope and I'll put channel 1 on the CS of U1 and channel 2 on CS of U2. The time we're interested in is between the rising edge of U1's CS and the falling edge of U2's CS. This should be sufficient enough that PI is sampled, right? So, basically, greater than 50 ns - at least 100 ns? The MCU, by the way, is working at 8 MHz. Thank you replying, by the way. I have nobody here to discuss it with and it really helps to go through about with someone who really knows what they're doing. :)if (nRESET = '0') then temp <= (others => '0'); shift_count := 0; elsif rising_edge(CLK) then if CS_rising = '1' then case cmd is when "00000001" => temp <= (others => '0'); temp(0) <= '1'; shift_count := 1; when "00001111" => temp <= (others => '0'); shift_count := 0; when "10101010" => temp <= temp(WIDTH - 2 downto 0) & '0'; shift_count := shift_count + 1; when "11110000" => ACK <= '1'; when others => null; end case; shift_count_vector <= std_logic_vector(to_unsigned(shift_count,shift_count_vector'length)); elsif CS_falling = '1' then ACK <= '0'; end if; end if; - Altera_Forum
With a 8 MHz MCU, I guess the time between CS_U1 going down up and CS_U2 going will probably be several times 125 ns. So, plenty of time to meet setup time.
And since you're not changing the values right after U2 samples them, plenty of time to meet hold time. Really, don't see why it's failing occasionally. That said.. - U2 samples PI at the rising edge of clk.. when CS_sync is '1', not CS. So, it's happening 2 clocks later. You probably have something similar in U1, so it evens out. But best keep it in mind. - The signal can take some time from U1 setting it and becoming stable at U2's inputs, because of the pull-up scheme, connection cable, etc. I've seen pull-up schemes being unexpectedly slow, so this would be my first guess. - Since there are two different boards, the clocks at U1 and U2 won't be in perfect phase and this may work against you too. Try to draw a timing diagram of the signals involved, it's usually worth the trouble. Try measuring the delay between the rising edge of U2's clock and PI[*] reaching a stable value. Try to get a min/max range for some of the 72 signals. This will be the min/max input delays you should to set on PI, by the way. Other nice things to measure may be the phase between U1's clock and U2's clock; and the time between U1's CS and U2's CS. - Altera_Forum--- Quote Start --- With a 8 MHz MCU, I guess the time between CS_U1 going down up and CS_U2 going will probably be several times 125 ns. So, plenty of time to meet setup time. And since you're not changing the values right after U2 samples them, plenty of time to meet hold time. Really, don't see why it's failing occasionally. That said.. - U2 samples PI at the rising edge of clk.. when CS_sync is '1', not CS. So, it's happening 2 clocks later. You probably have something similar in U1, so it evens out. But best keep it in mind. - The signal can take some time from U1 setting it and becoming stable at U2's inputs, because of the pull-up scheme, connection cable, etc. I've seen pull-up schemes being unexpectedly slow, so this would be my first guess. - Since there are two different boards, the clocks at U1 and U2 won't be in perfect phase and this may work against you too. Try to draw a timing diagram of the signals involved, it's usually worth the trouble. Try measuring the delay between the rising edge of U2's clock and PI[*] reaching a stable value. Try to get a min/max range for some of the 72 signals. This will be the min/max input delays you should to set on PI, by the way. Other nice things to measure may be the phase between U1's clock and U2's clock; and the time between U1's CS and U2's CS. --- Quote End --- If I remember correctly, the rising time of P[*] was a hundred or so ns long due to the 1K pull up. If the timing between U1's CS and U2's CS is too close, the simplest solution would be to just put a delay of a uS between them. Very easy in an AVR. The boards are the same i.e U1 and U2 are on the same board and share the same clock. Because this is just internal equipment we didn't care much about aesthetics - the wires just connect at one end, wrap around and connect on the other end. However, the board has the capability to be extended i.e. there's another board which only has CPLDs and no MCU. This board connects via ribbon cable to the 'main' board. Interestingly, the data transmission between the MCU and the CPLDs that are on same board as the MCU is always OK. I have, so far, never seen a bad data transfer between them. However, the other boards, which connect via the ribbon cause the issues. But as I said, even that was reduced drastically to be 1 in 10,000 data transfers now. The only difference is that the SCK, CS, SO and SI travel quite a bit more but at just 2 MHz (and 7 ns rise times) one would think that signal integrity wouldn't be an issue. The overshoot on these signals is 1.3 V but it settles quickly and there is no ringing. Perhaps I should slow down these signals even further? The system works great if SCK is 1 MHz, by the way. No bad transfers.
- Altera_Forum
That's a good test: change the speed of sys_clk vs SCK.
This way, you can pin-point which interface is giving you problems: the PO/PI or the SPI interface. Also, if the situation improves when you lower the operating frequency, there are two main possibilities. One, you have a setup timing problem. That means, some signal is taking too much time to become stable and, occasionally, it's samples before it has becomes stable. But again, with a 7 ns rise time I don't see that happening. Another possibility is Inter Symbol Interference: the signal of one bit overlaps with another one and as a result U2 samples the wrong value. You can try to take a look at the eye pattern of PI. Try to see if the error is specific to a given signal in the PI vector or if it's random. But you can pretty much discard hold violation issues. A third possibility: the problem is noise related and it's also happening at 1 MHz, you just haven't noticed it yet. - Altera_Forum
So I have some updates:
I think that the SO/MISO waveform is arriving a bit late. The difference between the falling edge of SO and the rising edge of SCK (where the MCU samples) is just 40 ns. I'm thinking that, occasionally, the waveform arrives too late and I get a bad transfer. The AVR datasheet states 10 ns for setup and hold but these are typical values. Min/max are not provided. Here's a o-scope picture with SCK at 2 Mhz. The top waveform is MISO and bottom is SCK. http://i.imgur.com/EQWzz.png Same waveforms at higher timebase: http://i.imgur.com/jUpqx.png and here's another picture with SCK at 1 MHz: http://i.imgur.com/ewmQj.png At 1 Mhz, the waveform arrives in time very comfortably but I think 2 MHz is a bit of an edge case. I'd prefer to make it arrive a bit earlier. I adjusted the SDC constraints but they had little effect. I'm beginning to think that it might be because of my design. The other thing I noticed is that my SCK's frequency doesn't stay constant - it increases to 2.1 Mhz and decreases some too. My guess is that because the MCU is running from it's internal RC oscillator. It could be that, once in a while, SCK's freq. increases just slightly and because of the very narrow time to setup MISO, it reads in a bad value? Tomorrow, I will calibrate the internal RC oscillator and see if SCK's performance improves. However, any suggestions on what to do with my CPLD design? Will I need to increase the sys_clk frequency if I want SCK t obe 2 MHz? A lot of designs can run at just 1/4th the system frequency but I'm having to run at less than 1/10th! Would appreciate any advice on where to go from here. - Altera_Forum
Oh!
So, the MCU runs on a internal RC oscillator and produces the SCK based on that? My first suggestion would be to run the SPI interface using the SCK and interfacing with sys_clk only when needed. Which begs the question: what's the purpose of sys_clk?
