Addition nicht rechtzeitig fertig - kann das sein?

Bronco schrieb:
> ich hatte vor kurzem eine Diskussion mit einem Kollegen, der deutlich
> mehr Berufserfahrung mit FPGAs hat als ich.

das scheint mir nicht der Fall zu sein. Diese Frage sollte jeder mit 
spätestens 3-6 Monaten FPGA-Erfahrung beantworten können.

Wer zudem für eine 16 Bit Addition extra einen IP-Core einsetzt arbeitet 
entweder
- extrem akademisch
- versucht möglichst viel zeit to zu schlagen
- versucht den Code unlesbar zu machen
- oder ist schlichtweg unfähig (erst recht mit "deutlich mehr 
Berufserfahrung")

Bronco schrieb:
> Ich hab ihn gefragt, warum er nicht einfach "A+B+C" hingeschrieben hat
> und er sagt, er glaubt beobachtet zu haben, daß die Additionsergebnisse
> nicht immer rechtzeitig zum nächsten Takt (48MHz, Spartan3) fertig sind.

Gut möglich.

Die Frage ist nur: warum setzt er kein Contraint auf den Takt, so das 
die Tools sicher stellen das dies erfüllt ist oder ggf melden das es 
nicht möglich ist?


Bronco schrieb:
> Meiner Meinung nach muß das funktionieren, solange die Toolchain keinen
> Fehler meldet

Solange die clock constraints richtig gesetzt sind stimmt das für diesen 
Fall auch.


Bronco schrieb:
> Aber er argumentiert, daß man der Toolchain (Xilinx ISE)
> nicht immer vertrauen kann

Immer würde ich das vielleicht auch nicht tun, aber in so einem Fall 
kann man das wohl, ansonsten könnte kein Mensch sinnvoll etwas 
entwickeln.

Bronco schrieb:
> Ich hab ihn gefragt, warum er nicht einfach "A+B+C" hingeschrieben hat
> und er sagt, er glaubt beobachtet zu haben, daß die Additionsergebnisse
> nicht immer rechtzeitig zum nächsten Takt (48MHz, Spartan3) fertig sind.
> Aber so richtig sicher ist er sich nicht.

Dann hat er die Constraints nicht richtig vorgegeben.
Ein Spartan3-2000 schafft die Addition von drei 16-Bit-Zahlen in ca. 170 
MHz.

Wenn die Constraints stimmen und alle relevanten Pfade erfasst werden, 
sind die Aussagen der Tools erfahrungsgemäß recht konservativ:

1

Timing Score: 0 (Setup: 0, Hold: 0, Component Switching Limit: 0)

2

3

Asterisk (*) preceding a constraint indicates it was not met.

4

   This may be due to a setup or hold violation.

5

6

----------------------------------------------------------------------------------------------------------

7

  Constraint                                |    Check    | Worst Case |  Best Case | Timing |   Timing   

8

                                            |             |    Slack   | Achievable | Errors |    Score   

9

----------------------------------------------------------------------------------------------------------

10

  TS_clk = PERIOD TIMEGRP "clk" 175 MHz HIG | SETUP       |     0.030ns|     5.684ns|       0|           0

11

  H 50%                                     | HOLD        |     1.224ns|            |       0|           0

12

----------------------------------------------------------------------------------------------------------

13

14

15

All constraints were met.

Duke

Danke für Eure Antworten, sonst wäre ich noch vom Glauben abgefallen ;)

Die Constraints sind übrigens richtig angegeben, es gibt auch keine 
Fehler oder Warnings. Gerade deswegen konnte ich ja auch nicht glauben, 
daß eine bestimmte Addition nicht korrekt ablaufen soll, wohingegen jede 
Menge anderer Addtionen alle korrekt funktionieren...

PS: ich konnte das ursächliche Fehlerverhalten übrigens nicht 
reproduzieren :-O