crazy behaviour of fpga, timing ?

If you are treating your IO pins as synchronous inputs, you need to assign timing constraints on the IOs and on your clock. Quartus does then a very good job at building correct delays to achieve timing coherence, but it cannot guess your constraints. You need to feed QII with accurate figures ! (garbage in garbage out)

Then, static timing analysis (post P&R indeed) will confirm that everything is fine (Tsu, Th figures in the timing reports).

STP II, being a synchronous logic analyzer, isn't the best tool for debugging timing issues. Timing sim can help, but you need to feed to with accurate timings indeed... back to square 1.

Last : a mux is combinational. If you pile up logic (combinational layers before the first FlipFlops, it becomes a difficult case (with a potentially high difference between shortest & longest path). If your IOs are resynchronized asap (before the combinational logic), then timing issues become Fmax issues, which are trivial.

Bert Cuzeau

Hi,

after I added an extra process which gets the data (without combinational logic) from the external device, everything worls fine (-: Thanks very much!

Alex

">

Thanks for the feedback. Apparently complex problems often have simple solutions :-)

But remember that, if your input are synchronous to a clock that you are using in the FPGA, you should define the constraints. Dependending on Frequency, your design usually has very high chances to "work" just by registering the I/Os in or near the IO cell, but that is not totally reliable... a change of speed grade, or a new batch of components may alter this. With proper constraints, it _will_ work, or you'll be warned by STA.

Bert Cuzeau

I looked in the Quartus manual an read the chapter on "timing analysis", but even the Webcast which is available from alter gave me no clue what to do. Is there some more literautre about this problems or an practical example ? I'm for example not sure at which time I would set the hold time ?

Wit best regards.

Alex

">> Hi,

Hi Bert,

I am facing a similar situation where I have to deal with an external bidirectional data bus + ctrl signals coming directly from the pins.

The problem is that I have no time to register the incoming signals so that I could work with the outputs of that register stages. Instead I have to send data on the bus directly.

So my question: When I use the pin signal (which is synchronous to the clock I use in the sampling process) what timing constraints or other "proper" constraints do you recommend ?

Thank you for your help.

Rgds André

Sorry, was out of the country for a few days.

The idea is that you need to tell Quartus when data at your input pins will change with respect to the external clock. In Quartus STA, this is called Tsu and Th assignments. There is some help available inside Quartus about the subject. But it's standard know-how, so I guess good books must teach it. I think Clive's nice and easy to read : "The Design Warrior's Guide to FPGAs"

has a chapter about STA (OTOMH, I don't have the book at hand)

In our 2-days Altera Design course, we spend over 3 hours (& 2 exercises) on STA and timing constraints. This is key to designs that work.

The situation can become more complex when you deal with isosynchronous clocks at fractional frequencies (like F2 = F1 *4/5). QII STA does even know how to calculate this kind of timings ! (I would still recommend async Fifos to cross such boundaries though)

Let me know if you really can't find the right information (which I doubt)

Bert Cuzeau

Very unclear to me. In a bidir, you have two worries :

- In data : this is Tsu & Th

- Out data : this is Tco and nobody can guess without knowing precisely what you have on the other end.

As of "having no time etc...", I fear the worst... (data used at several places in the design without any resynchronization : good luck in this case !)

btw : Leave the "Cut of feedback from IO pins option" to "On" (default) unless you read from yourself (very unlikely !)

-> don't use global constraints for your IOs since very likely only some pins will have these constraints.

Bert Cuzeau

I have some part (that is when I receive external data) which I can resynchronisize.

But there is also some portion (that is when I send data to external device) where I am not able to resynchronisize because external device is expecting data on the next clock cycle when asserting the control signal "NXT".

Do you mean that it is impossible to use external synchronous data in a state machine without resynchronization ? Why?

Thank you for your help.

Rgds Andr=E9

You have to know your design AND external device perfectly + assign the proper constraints + verify that they're met by STA. It's usually tricky since you won't catch problems at RTL simulation, and very likely not in timing sim either, so this pushes the discovery of problem at a very late stage of the design, hoping not too late...

Nothing is impossible, some ways are just more dangerous than others.

Bert Cuzeau

Bert,

I have an external USB transceiver which sends data to my FPGA. The spec. of the transceiver says the following:

output delay with respect to the positive edge of clock

tOUT (60MHz clock) 2pF - 12pF - 30pF 9 ns

So if I take into account a transceiver output pin capacitance of about of let's say 8pF and about 5pF of my FPGA input pins capacitance (also 5pF for clock input pin of FPGA) then I would have about the half of 30pF.

That clock-to-output time specification of the transceiver (I hope that it refers to the clock at user output pin) leads to the fact that maybe I need to delay my data in the FPGA input pins so that SETUP/HOLD is not violated.

Which constraint type does fulfill these delay requirements in the input pins? I mean : Under which name do I have to search in the Constraint Manager ?

Best regards Andr=E9

Good practice if you don't have timing is to assume each part should not use more than half of the period. Obviously this is not full proof but if you don't have any info this almost always will be ok for normal TTL/LVTTL signals.

As for reading yourself there are some application (e.g. more than one driver) so be careful one example is the clock signal of I2C where you need to "listen" to the bus while driving it As it is a line with Possible multidriver.

Have fun

I/O Tsu & Th

By definition : tsu = data delay - clock delay + intrinsic tsu th = clock delay - data delay + intrinsic th

PS : in the ps range, you probably should also take into account the PCB delays.

60 MHz isn't a too high freq, so it should be quite doable if there is a minimal skew between all the (synchronous) signals.

There is a way I don't dare to mention since everyone will (at best) frown at it : you can synchronize at one clock edge or the other and just try : one solution at least should give a 0 error rate, and hopefully the other should exhibit "some" errors, in which case you have found a decent solution. If both work... you'll need to do things more seriously. Very dirty but it worked once well for me (with the context of not very high clock freqs and in the absence of better characterization). I didn't tell you and I won't sign this post :-)

The clean & official way is better, but again you need reliable timing information on the data producer and all the delay elements. Keep also in mind that "worst case timing" is not necessarily your worst case... And I always found that a good scope was of great help.

Regards, Treb