mikrocontroller.net

Forum: FPGA, VHDL & Co. Paralelle Delay Zeiten


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Wolfram F. (mega-hz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich stehe vor einem Problem:

Es sollen zwei Eingänge (TTL) mit verschiedenen, per GPIB Befehlen 
kombenierbaren Logiken abgefragt und weiterbehandelt werden.
An 1 bis 8 Ausgängen sollen dann verschiedene Aktionen stattfinden.
Beispiel:

wenn IN1 steigende Flanke und IN2 = LO, dann OUT1 100µS warten (LO), 
500µS HI, 300µS warten (LO), fertig.

wenn IN2 fallende Flanke, OUT 3 100µS(LO),300µS(HI),10µS(LO),fertig

wenn IN1 und/oder IN2 steigende Flanke, OUT5 1000mS HI,1000mS(LO)

usw.

Das muss allerdings alles paralell laufen!

Ich habe EINE abfrage und das Timing bereits mit einem ATMEGA32
hinbekommen, aber in der Abarbeitungszeit kann er ja nicht gleichzeitig
andere Routinen erledigen.

Daher die Frage, würde das in einem PLD funktionieren? (ich denkke 
schon)
und wie könnte man dem PLD die gewünschte config der 
delays/ontimes/offtimes von einem µC "übergeben"?

Ich habe nicht sooo viel Erfahrungen mit VHDL, habe bislang erfolgreich 
Adressdecoder und Rom Mapper für einen 80er Jahre 8 Bit Rechner 
geschrieben.

Vielleicht gibt es ja auch bereits einen programmierbaren Chip der sowas 
könnte?

Wäre dankbar für Tips.

Gruß,
Wolfram.

: Bearbeitet durch User
Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wolfram F. schrieb:
> Ich habe EINE abfrage und das Timing bereits mit einem ATMEGA32
> hinbekommen, aber in der Abarbeitungszeit kann er ja nicht gleichzeitig
> andere Routinen erledigen.
Kommt drauf an, mit welcher Granularität, mit welchem Jitter, er das 
machen muss. Müssen das z.B. genau 10,000 µs (mit kleinem 's', sonst 
wäre das ein Leitwert mit "milli Siemens" und "mikro Siemens"(*)) sein, 
oder dürfen das auch mal 9 oder 11 µs sein?

Und natürlich darf in dem Code in keinster Weise irgendein wait() oder 
sleep() vorkommen.

> Vielleicht gibt es ja auch bereits einen programmierbaren Chip der sowas
> könnte?
Kommt wie gesagt ein wenig auf den erlaubten Jitter an...

> Daher die Frage, würde das in einem PLD funktionieren? (ich denkke
> schon)
Normalerweise dürfte das sogar in ein geräumig mit Flipflops 
ausgestattetes CPLD passen, denn die nötigen Zähler fressen die dort rar 
gesäten Makrozellen weg wie nichts. Allerdings gibt es nur noch wenige, 
die 5V TTL können. Xilinx hat schon mal nichts mehr. Und die alten 
Atmel-Microchip-CPLDs tun sich mit der alten Toolchain schwer.
Insofern wäre ein kleines FPGA vom Schlage MachXO mit seinem internen 
Oszillator vermutlich genau das, was hier gebraucht wird... ;-)

> wenn IN2 fallende Flanke, OUT 3 100µS(LO),300µS(HI),10µS(LO),fertig
Wenn der OUT 3 sowieso normalerweise Low ist, warum musst du dann zum 
Schluss noch 10µs warten?

(*) https://de.wikipedia.org/wiki/Siemens_(Einheit)

: Bearbeitet durch Moderator
Autor: Wolfram F. (mega-hz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
die Genauigkeit darf ca. +/- 2.5µs betragen.

die 3 Zeiten delay,ontime,offtime sollen verzögerung bis zum 
einschalten,
einschaltdauer und inaktivität sein, also in den 10µS offtime sollen die 
Eingänge ignoriert werden.

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wolfram F. schrieb:
> die Genauigkeit darf ca. +/- 2.5µs betragen.
Auch bei den ms-Zeiten? Oder dürfen die Zeiten prozentual um 25% 
abweichen?

> die 3 Zeiten delay,ontime,offtime sollen verzögerung bis zum
> einschalten,
> einschaltdauer und inaktivität sein, also in den 10µS offtime sollen die
> Eingänge ignoriert werden.
Wenn also In2 in der "Totzeit" eine fallende Flanke hat, soll mit dem 
Out3 bis zur nächsten fallenden Flanke vom In2 nichts passieren?

Autor: Wolfram F. (mega-hz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
>> die Genauigkeit darf ca. +/- 2.5µs betragen.
> Auch bei den ms-Zeiten? Oder dürfen die Zeiten prozentual um 25%
> abweichen?
die sollten im 5µs Bereich bleiben.

>
>> die 3 Zeiten delay,ontime,offtime sollen verzögerung bis zum
>> einschalten,
>> einschaltdauer und inaktivität sein, also in den 10µS offtime sollen die
>> Eingänge ignoriert werden.
> Wenn also In2 in der "Totzeit" eine fallende Flanke hat, soll mit dem
> Out3 bis zur nächsten fallenden Flanke vom In2 nichts passieren?
Genau.

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wolfram F. schrieb:
> Genau.
Dann sieht das nach einer netten kleinen Fingerübung für einen Lattice 
MachXO2, oder einer spannenden Aufgabe für einen AVR aus.

Ich würde selbstredend den MachXO2 nehmen. Da weiß ich vorher schon, 
dass es hinterher garantiert auf Bruchteile von µs genau realisierbar 
ist und laufen wird. Und wenn einer der 8 Ausgangskanäle das tut, was er 
soll, dann sind die restlichen 7 ein kleiner Klacks, denn dann muss die 
Komponente "Verzögerungsautomat mit 3 Zeiten" einfach 8 mal instantiiert 
werden und fertig...    ;-)

Autor: Wolfram F. (mega-hz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
aber wie kann man die zeiten und die Kombinationen, die ja frei wählbar 
sein sollen, vom µC an das FPGA/PLD übergeben?

Die angegebenen Zeiten sind ja nur Beispiele, und die verknüpfungen 
ebenfalls. Die können auch mehrfach sein...

: Bearbeitet durch User
Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wolfram F. schrieb:
> aber wie kann man die zeiten und die Kombinationen, die ja frei wählbar
> sein sollen, vom µC an das FPGA/PLD übergeben?
Dafür würde ich eine SPI Schnittstelle nehmen. Und durch diese Forderung 
"Speichern von Vergleichswerten" ist jetzt zwingend ein FPGA nötig, denn 
CPLD haben nicht genügend Flipflops dafür. Wenn dann z.B. eine 
Granularität von 1µs genommen wird, kann mit 3x 24 Bit Registern jede 
der drei Zeiten von 1µs bis zu 16777215µs, also fast 17s eingestellt 
werden.

> Die angegebenen Zeiten sind ja nur Beispiele, und die verknüpfungen
> ebenfalls. Die können auch mehrfach sein...
Dann muss die In1+2 Auswertung eben auch per Flags konfigurierbar 
gemacht werden. Dafür wäre dann ein Konfigurationsbyte nötig, das dann 
für jeden Kanal z.B. so aussieht:
Register "trigger"
Bit   7  6  5  4   3  2  1  0
      In2.......   In1.......   
                   |  |  |  '-> 1 = In1 beachten / 0 = In1 nicht auswerten
      wie In1      |  |  '----> 1 = Flanke / 0 = Pegel
                   |  '-------> 1 = High,Rise / 0 = Low,Fall
                   '----------> Reserve
Für die 3 Fälle aus dem Eröffnungspost sieht die Konfiguration der 
Kanäle dann so aus:
Wolfram F. schrieb:
> wenn IN1 steigende Flanke und IN2 = LO, dann OUT1 100µS warten (LO),
> 500µS HI, 300µS warten (LO), fertig.
trigger = 0001 0111 bin = 0x17
delay   = 100 dez
ontime  = 500 dez
offtime = 300 dez

> wenn IN2 fallende Flanke, OUT 3 100µS(LO),300µS(HI),10µS(LO),fertig
trigger = 0011 0000 bin = 0x30
delay   = 100 dez
ontime  = 300 dez
offtime = 10  dez


> wenn IN1 und/oder IN2 steigende Flanke, OUT5 1000mS HI,1000mS(LO)
trigger = 0111 0111 bin = 0x77
delay   = 1000000 dez
ontime  = 1000000 dez
offtime = 0       dez

Das wäre dann die zweite Fingerübung... 😉

Insgesamt müssen dann per SPI also 8x 10 Bytes (pro Ausgang 3x3 Bytes 
für die Zeiten plus 1 Byte für die Triggerbedingung) zur Konfiguration 
übertragen werden. Gleichzeitig könnten dann noch "kostenlos", weil SPI 
ja zeitgleich bidirektional ist, irgendwelche internen Zustände des 
FPGAs zurückgemeldet werden.

Wolfram F. schrieb:
> wenn IN1 und/oder IN2 steigende Flanke
Eine gleichzeitige Flanke gibt es in realer Hardware nicht, deshalb 
ist das "und" hier unnötig (bzw. eigentlich unmöglich).

: Bearbeitet durch Moderator
Autor: Wolfram F. (mega-hz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
danke dir, das sind gute denkanstösse!
Werde da mal ein paar Tage mir das durch den Kopf gehen lassen.

Cool wäre noch, wenn der µC dann auch gleich mit ins FPGA kommt, aber 
dafür reichen meine Kenntnisse lange nicht aus.

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wolfram F. schrieb:
> Cool wäre noch, wenn der µC dann auch gleich mit ins FPGA kommt
Dann wird halt das FPGA sehr groß und sehr teuer. Ein Softcore-µC im 
FPGA ist mit das Ineffizienteste, was man machen kann. Wenn das FPGA 
"sowieso" drauf und "viel zu groß" ist, dann kann man das schon machen. 
Aber man muss dann eben die Analoggeschichten, die so ein µC mitbringt 
(ADC, Oszillator, Brownout, Komparator...) extern an den Prozessor im 
FPGA anflanschen.

Bisher war die billigste Lösung (auch in Hinsicht auf Wartbarkeit und 
Softwaredesign) noch immer: optimaler µC + kleinstmögliches FGPA.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.