Lattice ECP3: IO Read Begrenzung

[Keller T. (fabito)]

Hallo leute,

Ich habe mein custom design(Lattice ECP3-LFE3-35EA-7FTN256I) aus ein vom 
Lattice
Reference Design(Versa ECP3-LFE3-35EA-8FN484C) abgeleitet.
Natürlich musste ich dann die Projekte-Eigenschafte anpassen:
Family
Device
Performance grade
Package type
Operation condition

Damit diese an mein neuen Baustein stimmen. Bisher war die Entwicklung 
und einfacher Test super gelaufen.
Die großte Änderung die ich implementiert habe betrifft nur das 
wb_tlc_dec.v
module in dem die IORequest übertragen werden im gegensatz zu Reference 
Design wo nur Memory Request behandelt werden.
4000-43ff: IO MAP (UART1,UART2)
5000-xxxx: MMAP (sonstige)

Dann habe ich seit letzter Montag das folgende Problem:

1)Lesen aus ein UART-Register durch loop bis 1000 klappt nicht
  Er liest problemlos bis 237 dann 5 Mal 0xFF danach bleibt das System 
hangen.


2)Wenn ich nun der Memory-Space 4000-43ff als MMAP definiere und der 
Test durclaufen lasse (20Uhr - 7 Uhr Morgen), wird die richtige Werte 
0xC1 gelesen bis 4000 000 loops dann meldest sich der Test Treiber ab. 
(Kling für mich as Timer Lattice IPCore bin ich nicht sicher)

Deswegen hätte ich gern ein Feedback von euch. Woran kann es liegen ?
beigefügt ist das einzige Module das ich geändert habe um die IO Request 
zu ermöglichen.

Ich bitte um Hinweise schon 4 Tagen ohne Lösung.....

 es gelingt mir bis(UART1,UART2)

[Duke Scarring (Gast)]

Sind alle asynchronen Signale richtig einsynchronisiert?

Duke

[Keller T. (fabito)]

Mein Logik Analyser sieht gut aus. Da ich mit dem Counter bis 234 
getriggert habe.(Reveal_Inserter.PNG und LogikAnalyser_Output.png)
Und 0xC1 Data ist im TLP Packet.(Sieht Bilder)
Hinzu habe ich auch mein topdesign damit du siehst wie die Clock 
verteilt sind.

Die UARTs brauchen 25 MHz. Die habe ich über PLL erzeugt.

Ich möchte mal das Lattice Basic Reference Design machen und nur IO 
Request im Module wb_tlc_dec.v zulassen.
Und der selbe Test beim Lesen GPIO Adresse 0002 durführen.
Ob ich problemlos 04 bis 1000 gelesen wird?
Im gpio Module steht :

      9'h002: begin
         if (rd) wb_dat_local <= 16'h1204;
      end

Oder bin ich auf dem falschen Lösungsweg ? vielleicht Routing Problem ?

[Lattice User (Gast)]

Das Verhalten deutet auf einen PCIe Protokollfehler.

Erstens,  das Naheliegende:

Was sagt die Timinganalyse.  sind die für PCIe nötigen 125 MHz noch 
erfüllt?

Zweitens:
Änderung Memory Access auf IO Access ist nicht trivial, IO Writes 
brauchen im Gegensatz zu Memory Writes eine Completion. Und 
Intelchipsätze reagieren allergisch auf fehlende Completions.
Die Erzeugung von Completions ist beim Lattice Core in der Verantwortung 
des Userscodes.
Ob der Latticewrapper dessen Source du hast, die Erzeugung von 
Completions für IO Writes enthält habe ich nicht nachgeprüft.

Davon abgesehen: IO Access ist angefaultes Legacy!

[Keller T. (fabito)]

OK !

beigefügt ist meine Timing Analysis: sieht diese versprechend aus oder 
sieht man kritishe Punkte drin ?

Nach der Lattice Beschreibungen sind die Completions TLP in folgende 
Module behandelt: wb_tlc_cpld.v und wb_tlc_cpld_fifo.v

Und es scheint als Memory sowie IO TLP Completion generiert werden. Aber 
ich bin noch nicht ganz sicher, ich analysiere noch den Inhalt.

[Lattice User (Gast)]

Es geht nicht um die IO Timing Analyse, die ist relativ unwichtig.

Place&Route Trace ist was du dir anschauen MUSST

[Lattice User (Gast)]

>
> Und es scheint als Memory sowie IO TLP Completion generiert werden. Aber
> ich bin noch nicht ganz sicher, ich analysiere noch den Inhalt.

Bei Memoryaccess braucht nur Read eine Completion, die gelesenen Daten 
müssen ja zurück :-)

Memory Write ist postet und braucht keine.

Bei IO Access mus auch für Write eine Completion erzeugt werden, ohne 
Daten.
(siehe PCIe Spec 2.2.9)

[Keller T. (fabito)]

Danke für den Hinweis!

Hier meine Routing Report. Gibt es Problem damit ?
Wenn ja wie kann man es verbessern ?

[Keller T. (fabito)]

OK ,

Wenn ich ein IORead mache, habe ich den richtige Daten. Das Problem 
tritt nur wenn nacheinander gelesen wird.
Also in meinem Verstandnis werden IO TLP vom cpld Module behandelt aber 
nicht vollstanding oder bist du andere Meinung ?

[Lattice User (Gast)]

keller thomas schrieb:
> Danke für den Hinweis!
>
> Hier meine Routing Report. Gibt es Problem damit ?
> Wenn ja wie kann man es verbessern ?

Timing summary (Setup and Hold):
---------------
Timing errors: 0 (setup), 0 (hold)
Score: 0 (setup), 0 (hold)
Cumulative negative slack: 0 (0+0)
--------------------------------------------------------------------------------

Das sieht ok, aus.

Aber die 125 MHz sind nur ganz knapp erfüllt, d.h. du musst bei jedem 
bauen
überprüfen ob nich alles in Ordnung ist.

FREQUENCY NET "clk_125_c" 125.000000 MHz (0 errors)
4096 items scored, 0 timing errors detected.
Report: 125.960MHz is the maximum frequency for this preference.

Ausserdem:

Constraints cover 184729 paths, 104 nets, and 62958 connections (96.1% coverage)

96% ist IMO zu wenig, da fehlen Constraints.

[Lattice User (Gast)]

keller thomas schrieb:
> OK ,
>
> Wenn ich ein IORead mache, habe ich den richtige Daten. Das Problem
> tritt nur wenn nacheinander gelesen wird.
> Also in meinem Verstandnis werden IO TLP vom cpld Module behandelt aber
> nicht vollstanding oder bist du andere Meinung ?

Dein wb_tlc_cpld.v erzeugt nur die Completions für die WB Lesezugriffe.

Überprüfe mal ob für die IO Zugriffe eventuell auch UR Completions 
erzeugt werden (UR = Unsupported Request)

(Das ganze schreit nach einem PCIe Analyzer)

[Keller T. (fabito)]

Nach deiner Anmerkung habe ich nochmals das ganze angeschaut.
Die Äderung die ich im Module wb_tlc_dec.v gemacht habe allein reicht 
nicht
für eine effiziente Behandlung der IO TLP Transaction.
Sondern folgende Module sollen auch entprechend für eine effiziente IO 
Completion geändert werden:

UR.v
ip_rx_crpr.v

1 ) also insgesamt 3 Module meiner Meinung nach angepasst werden. Bisher 
habe ich nur wb_tlc_dec.v mit folgende hinzugefügt um IO Request zu 
laasen:

//////////////////////// IO Write Packets ////////////////////////////////////////
       8'b00x0_0010: // IO-Rd    
        begin
          fifo_wrn_p <= 1'b0;          
          drop <= 1'b0;
        end 
      8'b01x0_0010: // IO-Wr
        begin
          fifo_wrn_p <= 1'b1;          
          drop <= 1'b0;
        end  
///////////////////////////////////////////////////////////////////////////

2) Wie kann man die Contraints verbessern ?

[Keller T. (fabito)]

Ich habe folgende Ändeung gemacht und hoffe das Problem gelöst zu haben.
Also ich bin gespannt auf das Ergebnis mit dem Test.

Im UR.v Module:

    ///////vorher///////
        /*8'b0000_0010: begin //IO Rd
           one_nph <= 1'b1;
        end
        8'b0100_0010: begin //IO Wr
           one_nph <= 1'b1;
           one_npd <= 1'b1;
        end*/
    ///////Nach Änderung ////////
        8'b0000_0010: begin //IO Rd
                if (~(rx_bar_hit[1] || rx_bar_hit[0])) //8'h40: // IOWr to BAR other than 0 or 1
            one_nph <= 1'b1;
        end
        8'b0100_0010: begin //IO Wr
          if (~(rx_bar_hit[1] || rx_bar_hit[0]))
          begin            
            one_ph <= 1'b1;
            one_pd <= 1'b1;
            sm <= e_DATA_LEN;
          end
        end

Und im iprxcrpr.v Module:

        //////vorher/////////
        /*8'b0000_0010: begin //IO Rd
           one_nph <= 1'b1;
        end
        8'b0100_0010: begin //IO Wr
           one_nph <= 1'b1;
           one_npd <= 1'b1;
        end*/
    ///////Nach Änderung ////////
        8'b0000_0010: begin //IO Rd
                if (~(rx_bar_hit[1] || rx_bar_hit[0])) //8'h40: // IOWr to BAR other than 0 or 1
            one_nph <= 1'b1;
        end
        8'b0100_0010: begin //IO Wr
          if (~(rx_bar_hit[1] || rx_bar_hit[0]))
          begin            
            one_ph <= 1'b1;
            one_pd <= 1'b1;
            sm <= e_DATA_LEN;
          end
        end

Und die damalige Änderung gilt immer also
im wb_tlc_dec.v Module

/*//// Vorher //////
        casex (rx_din[c_DATA_WIDTH-1:c_DATA_WIDTH-8])
        8'b00x0_0000: // MRd
        begin
          fifo_wrn_p <= 1'b0;          
          drop <= 1'b0;
        end 
        8'b01x0_0000: // MWr
        begin
          fifo_wrn_p <= 1'b1;          
          drop <= 1'b0;
        end        
        default:  // Unsuppored by WB
    */
 ///// Nach Änderung ////////
        casex (rx_din[c_DATA_WIDTH-1:c_DATA_WIDTH-8])
        8'b00x0_0000: // MRd
        begin
          fifo_wrn_p <= 1'b0;          
          drop <= 1'b0;
        end 
        8'b01x0_0000: // MWr
        begin
          fifo_wrn_p <= 1'b1;          
          drop <= 1'b0;
        end 
        8'b00x0_0010: // IO-Rd   
        begin
          fifo_wrn_p <= 1'b0;          
          drop <= 1'b0;
        end 
        8'b01x0_0010: // IO-Wr
        begin
          fifo_wrn_p <= 1'b1;          
          drop <= 1'b0;
        end  
    default:  // Unsuppored by WB

[Lattice User (Gast)]

Das ist falsch!

        8'b0100_0010: begin //IO Wr
          if (~(rx_bar_hit[1] || rx_bar_hit[0]))
          begin            
            one_ph <= 1'b1;
            one_pd <= 1'b1;
            sm <= e_DATA_LEN;
          end

IO Writes sind im Gegensatzt zu Memorywrites NON POSTET, d.h. dier 
muss genau wie im UR stehen:

        8'b0100_0010: begin //IO Wr
          if (~(rx_bar_hit[1] || rx_bar_hit[0]))
          begin            
            one_nph <= 1'b1;
            one_npd <= 1'b1;
            sm <= e_DATA_LEN;
          end

Ausserdem fehlt noch die Erzeugung der IO Write Completions, dafür gibt 
es im Latticecode kein Vorbild! (Memory Writes brauchen das nicht)

[Keller T. (fabito)]

IO transactions requests are restricted to 32 bits of address using the 
3DW TLP Header format, and should only target legacy devices.

Since PCI Express still permits either 32 bit or 64 bit memory 
addressing but the size of System IO Map is limited to 32 
bits(4GB),although in many system only lower 16 bits(i.e 64 KBs) are 
used.

So you can customize the existing code as per your requirement in order 
to account for IO request and should be responsible for sending an 
Unsupported Request completion based on the capabilities of your 
customized design.

For example, if in case your custom design only works with IO 
transactions and not memory transactions, then memory transactions are 
unsupported. These types of transactions require an Unsupported Request 
completion.

However there are several instances in which an Unsupported Request must 
be generated by the user. These conditions are
listed below.

• rx_us_req port goes high with rx_st indicating a Memory Read Locked, 
Completion Locked, or Vendor Defined
Message.
• Type of TLP is not supported by the user's design (I/O or memory 
request)
Table 2 in ipug75 on page 35 shows the types of unsupported TLPs which 
can be received by the IP core and the user interaction.


Link to download ipug75

http://www.latticesemi.com/~/media/Documents/UserManuals/MQ/PCIExpress11x1x4IPCoreUsersGuide.PDF#search=%22ipug75%22

[Keller T. (fabito)]

Hallo Hier die Anworte vom Lattice Support:
IO transactions requests are restricted to 32 bits of address using the 
3DW TLP Header format, and should only target legacy devices.

Since PCI Express still permits either 32 bit or 64 bit memory 
addressing but the size of System IO Map is limited to 32 
bits(4GB),although in many system only lower 16 bits(i.e 64 KBs) are 
used.

So you can customize the existing code as per your requirement in order 
to account for IO request and should be responsible for sending an 
Unsupported Request completion based on the capabilities of your 
customized design.

For example, if in case your custom design only works with IO 
transactions and not memory transactions, then memory transactions are 
unsupported. These types of transactions require an Unsupported Request 
completion.

However there are several instances in which an Unsupported Request must 
be generated by the user. These conditions are
listed below.

• rx_us_req port goes high with rx_st indicating a Memory Read Locked, 
Completion Locked, or Vendor Defined
Message.
• Type of TLP is not supported by the user's design (I/O or memory 
request)
Table 2 in ipug75 on page 35 shows the types of unsupported TLPs which 
can be received by the IP core and the user interaction.


Link to download ipug75

http://www.latticesemi.com/~/media/Documents/UserManuals/MQ/PCIExpress11x1x4IPCoreUsersGuide.PDF#search=%22ipug75%22

[Keller T. (fabito)]

Hallo,

nun meine Frage glaubst du dass, das Problem nur mit Änderungen
von 2 Modules:
UR.v
und
wb_tlc_dec.v

gelöst wird ?

Da Lattice Support nicht über das Module iprxcrpr.v spricht ?

[Keller T. (fabito)]

Hallo

Ich verstehe nicht was ich falsch gemacht, da du das selbe Code 
eingefügt hast.
Kannst du bitte genauer meinen Fehler erlautern ?

[Lattice User (Gast)]

keller thomas schrieb:
> Hallo
>
> Ich verstehe nicht was ich falsch gemacht, da du das selbe Code
> eingefügt hast.

Du musst genauer hinschauen, ist nicht derselbe.

            one_ph <= 1'b1;
            one_pd <= 1'b1;

versus

            one_nph <= 1'b1;
            one_npd <= 1'b1;

> Kannst du bitte genauer meinen Fehler erlautern ?

Das geht sehr ins Eingemachte, und nur einfach zu erkären wenn du weisst 
wie bei PCIe Flusskontrolle implementiert wird, was der Unterschied 
zwischen Postet und Non Postet Requests ist, und noch einiges mehr.

[Keller T. (fabito)]

Hallo Gute Nachricht!

Es tut schon beim Lesen!!!!!!!!!
Habe ich 100 000 000 Loop problemlos gelesen!
Nun soll ich auch Write schaffen und da ist mir beim Credit Processing 
noch nicht klar.

reicht folgende Code für IO Write ?

    case (sm)    
    e_IDLE: // wait for TLP
    begin  
      // Decode Type of Request
      if (rx_st) begin
        sm <= e_WAIT;
        casex (rx_din[15:8])
        //8'h00: // MRd to BAR other than 0 or 1
        8'b00x0_0000: //0000_0000 for 3DW mrd; 0010_0000 for 4DW mrd; 
        begin
          if (~(rx_bar_hit[1])) //8'h40: // MWr to BAR other than 0 or 1
            one_nph <= 1'b1;
        end
        8'b00x0_0001: //0000_0001 for 3DW mrdlk; 0010_0001 for 4DW mrdlk 
          one_nph <= 1'b1;
        8'b01x0_0000: //0100_0000 for 3DW mwr; 0110_0000 for 4DW mwr
        begin
          if (~(rx_bar_hit[1]))
          begin            
            one_ph <= 1'b1;
            one_pd <= 1'b1;
            sm <= e_DATA_LEN;
          end
        end
        8'b0000_0010: begin //IO Rd
          if (~(rx_bar_hit[0])) //8'h40: // IORd to BAR other than 0
            one_nph <= 1'b1;
        end
        8'b0100_0010: begin //IO Wr
     if (~(rx_bar_hit[0])) 
           one_nph <= 1'b1;
           one_npd <= 1'b1;
        end

[Lattice User (Gast)]

keller thomas schrieb:
> Hallo Hier die Anworte vom Lattice Support:
> IO transactions requests are restricted to 32 bits of address using the
> 3DW TLP Header format, and should only target legacy devices.

Dem schliesse ich mich an, angefaultes stinkendes Legacy.
Warum willst du es eigentlich machen? DOS 3.3? Windows 95/98?

>
> Since PCI Express still permits either 32 bit or 64 bit memory
> addressing but the size of System IO Map is limited to 32
> bits(4GB),although in many system only lower 16 bits(i.e 64 KBs) are
> used.
>

Das bedeutet nur, dass du IO Requests mit 4 DW Headern als UR ablehnen 
sollst. Ist relativ unkritisch, da diese normalerweise nicht vorkommen 
sollten. (Ausser in Verifications Umgebungen)

[Lattice User (Gast)]

keller thomas schrieb:
> Hallo Gute Nachricht!
>
> Es tut schon beim Lesen!!!!!!!!!
> Habe ich 100 000 000 Loop problemlos gelesen!
> Nun soll ich auch Write schaffen und da ist mir beim Credit Processing
> noch nicht klar.
>
> reicht folgende Code für IO Write ?

Nein, IO Write braucht wie schon mehrmals erwähnt eine Completion (nur 
Header ohne Daten)!

[Keller T. (fabito)]

Hilfe!

Es klappt immer noch nicht mit dem IO-Write:

So sieht mein ip_rx_crpr.v Module aus. Aber dann hat mein Board nicht 
mehr
gebootet:

        8'b0100_0010: begin //IO Wr
      if (~(rx_bar_hit[0])) //8'h40: // IO-Wr to BAR other than 0
           one_nph <= 1'b1;
        end

BAR-0 is IO MAP
BAR-1 is MMAP

Was mache ich falsch da. Ich habe nur Header da gelassen oder fehlt mir 
noch was ?

[Lattice User (Gast)]

Du hast etwas falsch verstanden, es geht nicht um den empfangenen Header 
der war vorher schon in Ordnung.

Completion ist ein Antwortpacket das NACH einem IO Write generiert 
werden muss, genau wie bei IO Read aber ohne Daten.
Am einfachsten dürfte es sein, das in wb_tlc_cpld.v und 
wb_tlc_cpld_fifo.v mit einzubauen, aber beachten dass es bei Memory 
Writes NICHT gemacht wird.

[Keller T. (fabito)]

Hallo,

letztendlich habe ich das Module ip_rx_crpr.v wie folgenden gelassen.
Folglich klappt es im UART-Register zu schreiben.

case (sm)    
    e_IDLE: // wait for TLP
    begin  
      // Decode Type of Request
      if (rx_st) begin
        sm <= e_WAIT;
        casex (rx_din[15:8])
        //8'h00: // MRd to BAR other than 0 or 1
        8'b00x0_0000: //0000_0000 for 3DW mrd; 0010_0000 for 4DW mrd; 
        begin
          if (~(rx_bar_hit[1])) //8'h40: // MWr to BAR other than 0 or 1
            one_nph <= 1'b1;
        end
        8'b00x0_0001: //0000_0001 for 3DW mrdlk; 0010_0001 for 4DW mrdlk 
          one_nph <= 1'b1;
        8'b01x0_0000: //0100_0000 for 3DW mwr; 0110_0000 for 4DW mwr
        begin
          if (~(rx_bar_hit[1]))
          begin            
            one_ph <= 1'b1;
            one_pd <= 1'b1;
            sm <= e_DATA_LEN;
          end
        end
        8'b0000_0010: begin //IO Rd
          if (~(rx_bar_hit[0])) //8'h40: // IO-Rd to BAR other than 0
            one_nph <= 1'b1;
        end
        8'b0100_0010: begin //IO Wr
      if (~(rx_bar_hit[0])) //8'h40: // IO-Wr to BAR other than 0
           one_nph <= 1'b1;
           one_npd <= 1'b1;
        end
        8'b00110xxx: // Msg
        begin
          one_ph <= 1'b1;
        end      
        8'b01110xxx: // MsgD
        begin
          one_ph <= 1'b1;
          one_pd <= 1'b1;
          sm <= e_DATA_LEN;
          //pd_num <= rx_din[38:32]; // get length
          //pd_num <= (rx_din[1:0] == 2'b00) ? rx_din[9:2] : (rx_din[9:2] + 1); // get length        
        end      
        8'h44: // CfgWr0
        begin
          one_nph <= 1'b1;
          one_npd <= 1'b1;
        end
        ..........

[Lattice User (Gast)]

Was ist mit der Completion?

[Keller T. (fabito)]

Es hat geklappt aber ich habe das Gefühl dass, es eine kleine 
Verzögerung beim IOWrite gibt.
Sonst es funktioniert...
Hat das wahrscheinlich mit der Completion zu tun ? Wenn dann wie kann 
ich diese verbessern ?

[Keller T. (fabito)]

Hallo,

bitte wie kann ich IO Completion implementieren, dafür habe ich leider
kein Ausgangspunkt.

[Lattice User (Gast)]

keller thomas schrieb:
> Es hat geklappt aber ich habe das Gefühl dass, es eine kleine
> Verzögerung beim IOWrite gibt.
> Sonst es funktioniert...
> Hat das wahrscheinlich mit der Completion zu tun ?

Ja hat es.
Der Intelchipsatz, ist da gutmütig, d.h. er macht nach einem Completion 
Timeout einfach weiter. (Beim Lesen bekommt man dann 0xFFFFFFFF).
Es gibt aber andere. (Nvidia Ion friert ein).

Siehe auch ein frühres Posting:
Beitrag "Re: Lattice ECP3: IO Read Begrenzung"

[Keller T. (fabito)]

OK das habe ich auch verstanden!
Wo was getan werden soll ist meine Frage. Also ich weiße nicht wo ich 
damit anfangen soll.

[Lattice User (Gast)]

keller thomas schrieb:
> OK das habe ich auch verstanden!
> Wo was getan werden soll ist meine Frage. Also ich weiße nicht wo ich
> damit anfangen soll.

Chapter 2.2.9 in der PCIe Spec 2.1 lesen und verstehen.
Dannach verstehen was in der wb_tlc_cpld.v genau gemacht wird.
Wenn das klar ist, versuchen die FSM in der wb_tlc_cpld.v zu ergänzen.

[Keller T. (fabito)]

Danke für den Hinweis und ich werde es machen.
Nach der Implementierung und Test melde ich mich......

[Keller T. (fabito)]

Hallo,

Nach dem Lesen von
soll folgende angepasst werden:

 if (read) begin
         sm <= ACK; 
         dout_sop <= 1'b1;
         dout_wen <= 1'b1;
         dout <= {8'h4a, 1'b0, tran_tc, 4'd0};
      end
    end
    ACK: // write header parts
    begin
      dout_wen <= 1'b1;
      dout_sop <= 1'b0;
      case (word_cnt)
         0: dout  <= {2'b00, tran_attr, 2'b00, tran_length};
         1: dout  <= comp_id; 
         2: dout  <= {3'b000, 1'b0, bc};
         3: dout  <= tran_id[23:8];
         4: dout  <= {tran_id[7:0], 1'b0, la};
      endcase

man soll IO Write auch hier berücksichtigen also nicht nur Memory Read 
wie jetzt der Fall ist oder ?
Das werde ich Morgen implementieren und testen ..

[Keller T. (fabito)]

So sieht meine Completion für IOWrite TLP aus:

    //  if (read) begin                                                     VORHER
  if ((read)|| (~read && (rx_bar_hit[0])) read or write on BAR0 (IOWr) // NEUE
         sm <= ACK; 
         dout_sop <= 1'b1;
         dout_wen <= 1'b1;
         dout <= {8'h4a, 1'b0, tran_tc, 4'd0}; // first 16'b from Completion Header Fields
      end
    end
    ACK: // write header parts
    begin
      dout_wen <= 1'b1;
      dout_sop <= 1'b0;
      case (word_cnt)
         0: dout  <= {2'b00, tran_attr, 2'b00, tran_length};
         1: dout  <= comp_id; // CompletionID 16'b
         2: dout  <= {3'b000, 1'b0, bc}; // 16'b
         3: dout  <= tran_id[23:8];              //Request ID = 16'b
         4: dout  <= {tran_id[7:0], 1'b0, la};   // Tag + R + Lower Adresse = 16'b
      endcase
      
      if (word_cnt == 4) begin                                         // VORHER    
         if (~read && (rx_bar_hit[0])) begin                           // NEU: HINZU
        dout_eop <= 1'b1;
            sm <= CLEAR;
      end
     else begin
        sm <= DAT;
            word_cnt <= 1;
            end
    end
      else
         word_cnt <= word_cnt + 1;
    end
    DAT: // write data parts

Damit bin ich mit der IOWrite Completion fertig oder hast du weitere 
Anmerkung?

[Keller T. (fabito)]

Hat leider nicht geklappt,

IORead klappt damit nicht mehr
Hier meine neue Implementierung:

    case (sm)
    IDLE:
    begin
      word_cnt <= 0;
      dout_eop <= 1'b0;
    //  if (read) begin   VORHER
  if ((read)|| (rx_din[15:8]== 8'b01x0_0010)) begin //read or write on BAR0 (IOWr) // NEUE
         sm <= ACK; 
         dout_sop <= 1'b1;
         dout_wen <= 1'b1;
         dout <= {8'h4a, 1'b0, tran_tc, 4'd0}; // first 16'b from Completion Header Fields
      end
    end
    ACK: // write header parts
    begin
      dout_wen <= 1'b1;
      dout_sop <= 1'b0;
      case (word_cnt)
         0: dout  <= {2'b00, tran_attr, 2'b00, tran_length};
         1: dout  <= comp_id; // CompletionID 16'b
         2: dout  <= {3'b000, 1'b0, bc}; // 16'b
         3: dout  <= tran_id[23:8];              //Request ID = 16'b
         4: dout  <= {tran_id[7:0], 1'b0, la};   // Tag + R + Lower Adresse = 16'b
      endcase
      
      if (word_cnt == 4) begin                                         // VORHER    
         if (rx_din[15:8]== 8'b01x0_0010) begin                           // NEU: HINZU
        dout_eop <= 1'b1;
            sm <= CLEAR;
      end
     else begin
        sm <= DAT;
            word_cnt <= 1;
            end
    end
      else
         word_cnt <= word_cnt + 1;
    end

Auf Hinweis würde ich mich freuen...

[Lattice User (Gast)]

rx_din[15:8] und rx_bar_hit sind ganz sicher nicht mehr gültig.

Du brauchst ein zusätzliches Signal entsprechend "read", das ein iowrite 
durchreicht.

tran_length muss bei write completions auf 0 gesetzt werde, es wird ja 
nur der Header gesendet.

"bc" muss 4 sein, aber ob für "la" die byte enables ausgwertet werden 
sollen
kann ich dir jetzt nicht mit Sicherheit sagen, ich vermute nein.

(Immer daran denken, iowrite ist verfaultest Legacy, und die Behandlung 
von cfgwrites nimmt uns der core ab)

[Keller T. (fabito)]

Es gelingt mir nicht Tabelle 2-21 und 2-22 in der Spezifikation zu 
finden.
schaue Mal
http://iu4ever.org/files/Skhemotekhnika_JEVS9/1697_Skhemotekhnika_JEVS9_PCI_Express_Base_r2_1.pdf

Kannst du bitte mir diese 2 Tabelle zukommen lassen ?

Ich wäre denkbar

[Keller T. (fabito)]

Wenn dies sich au Power Management Messages bezieht dann habe ich....
Ich habe mit TLP gerechnet und nicht mit Power Message da ich keine 
Zusammenhang sehe.

[Lattice User (Gast)]

Die Tabellennumerierung im Latticecode bezieht sich offensichtlich noch 
auf die PCIe Spec 1.1

In der 2.1 Spec sind das jetzt die Tabellen 2.31 und 2.32

[Keller T. (fabito)]

Danke,

Mit tran_length = 0 verstehe ich aber bc =4 ist mir unklar weil:
 wenn First_BE = 0xF = 1111 dann BC=4

aber hier habe ich mein IOWr Paket angeschaut und First_BE=0x1=0001 also 
würde ich damit BC= 1 erwarten oder ?

[Lattice User (Gast)]

>
> Mit tran_length = 0 verstehe ich aber bc =4 ist mir unklar weil:
>  wenn First_BE = 0xF = 1111 dann BC=4
>
> aber hier habe ich mein IOWr Paket angeschaut und First_BE=0x1=0001 also
> würde ich damit BC= 1 erwarten oder ?

In 2.9 Completion Rules steht, dass der BC für alle Completions ausser 
Memory Reads (und AtomicOPs hier irrelevant) 4 sein muss.
Das schliesst auch IO Reads mit ein!

[Keller T. (fabito)]

Hallo ,

Ich habe schon fast alles bisher probiert.
Leider klappt es immer noch nicht.
Ich bitte um Hilfe!

module wb_tlc_cpld(wb_clk, rstn,
                din, sel, read, valid,
                tran_id, tran_length, tran_be, tran_addr, tran_tc, tran_attr, comp_id,
                dout, dout_sop, dout_eop, dout_wen,rx_din
);

input wb_clk;
input rstn;
input [15:0] din;
input [1:0] sel;
input read;
input valid;
input [23:0]  tran_id;  // tran_id = {req_id,tag}
input [9:0] tran_length;
input [7:0] tran_be;
input [4:0] tran_addr;
input [2:0] tran_tc;
input [1:0] tran_attr;
input [15:0] comp_id;
output [15:0] dout;
output dout_sop;
output dout_eop;
output dout_wen;
input  [15:0] rx_din;

reg [2:0] sm;
parameter IDLE = 3'b000,          
          ACK = 3'b001,
          DAT = 3'b010,
          CLEAR = 3'b011;


reg [15:0] dout, din_p, din_p2, din_p3, din_p4, din_p5;
reg dout_sop, dout_eop, dout_wen;
reg [11:0] bc;
reg [6:0] la;
reg valid_p, valid_p2, valid_p3, valid_p4, valid_p5;
reg [10:0] word_cnt;


always @(negedge rstn or posedge wb_clk)
begin
  if (~rstn)
  begin
    sm <= IDLE;
    dout <= 0;
    dout_sop <= 1'b0;
    dout_eop <= 1'b0;
    din_p <= 0;
    din_p2 <= 0;
    din_p3 <= 0;
    din_p4 <= 0;
    din_p5 <= 0;
   
    valid_p <= 1'b0;
    valid_p2 <= 1'b0;
    valid_p3 <= 1'b0;
    valid_p4 <= 1'b0;
    valid_p5 <= 1'b0;
    
    dout_wen <= 1'b0;
    la <= 7'b0000000;
    bc <= 0;
    word_cnt <= 0;
  end
  else
  begin
    din_p <= din;
    din_p2 <= din_p;  // pipe data to allow for header
    din_p3 <= din_p2;
    din_p4 <= din_p3;
    din_p5 <= din_p4;
    valid_p <= valid;
    valid_p2 <= valid_p; 
    valid_p3 <= valid_p2;  
    valid_p4 <= valid_p3;  
    valid_p5 <= valid_p4;  
  
  case (sm)
    IDLE:
    begin
      word_cnt <= 0;
      dout_eop <= 1'b0;
      if (read) begin
         sm <= ACK; 
         dout_sop <= 1'b1;
         dout_wen <= 1'b1;
         dout <= {8'h4a, 1'b0, tran_tc, 4'd0};
         end
    else if ((~read) && (rx_din[15:8]== 8'b01x0_0010))begin
         sm <= ACK; 
         dout_sop <= 1'b1;
         dout_wen <= 1'b1;
         dout <= {8'h0a, 1'b0, tran_tc, 4'd0};
         end
    end
    ACK: // write header parts
    begin
      dout_wen <= 1'b1;
      dout_sop <= 1'b0;
       if (read) begin
    case (word_cnt)
         0: dout  <= {2'b00, tran_attr, 2'b00, tran_length};
         1: dout  <= comp_id; 
         2: dout  <= {3'b000, 1'b0, bc};
         3: dout  <= tran_id[23:8];
         4: dout  <= {tran_id[7:0], 1'b0, la};
      endcase
      end
    else if ((~read) && (rx_din[15:8]== 8'b01x0_0010))begin
    case (word_cnt)
         0: dout  <= {2'b00, tran_attr, 2'b00, 10'd0};
         1: dout  <= comp_id; 
         2: dout  <= {3'b000, 1'b0, 12'd4}; // 16'b
         3: dout  <= tran_id[23:8];
         4: dout  <= {tran_id[7:0], 1'b0, la};
      endcase
    end
    
      if (word_cnt == 4) begin
     if ((~read) && (rx_din[15:8]== 8'b01x0_0010))begin
      dout_eop <= 1'b1;
          sm <= CLEAR;
          end
     else begin
     sm <= DAT;
         word_cnt <= 1;
         end
     end
     else
        word_cnt <= word_cnt + 1;
    end
    DAT: // write data parts
    begin
      dout_wen <= valid_p5;
      dout <= din_p5;
      if (valid_p5) begin
         if (word_cnt == {tran_length, 1'b0}) begin
            dout_eop <= 1'b1;
            sm <= CLEAR;
         end
         else
            word_cnt <= word_cnt + 1;
      end
    end    
    CLEAR: // clean up  
    begin
      dout_wen <= 1'b0;      
      dout_eop <= 1'b0;      
      sm <= IDLE;
    end
    
    endcase


    // implementation of table 2-21 from PCIe base spec
    //tran_be = first, last
    casex(tran_be)
    8'b1xx10000: bc <= 12'h004;
    8'b01x10000: bc <= 12'h003;
    8'b1x100000: bc <= 12'h003;
    8'b00110000: bc <= 12'h002;
    8'b01100000: bc <= 12'h002;
    8'b11000000: bc <= 12'h002;
    8'b00010000: bc <= 12'h001;
    8'b00100000: bc <= 12'h001;
    8'b01000000: bc <= 12'h001;
    8'b10000000: bc <= 12'h001;
    8'b00000000: bc <= 12'h001;
    8'bxxx11xxx: bc <= (tran_length*4);
    8'bxxx101xx: bc <= (tran_length*4) - 1;
    8'bxxx1001x: bc <= (tran_length*4) - 2;
    8'bxxx10001: bc <= (tran_length*4) - 3;
    8'bxx101xxx: bc <= (tran_length*4) - 1;
    8'bxx1001xx: bc <= (tran_length*4) - 2;
    8'bxx10001x: bc <= (tran_length*4) - 3;
    8'bxx100001: bc <= (tran_length*4) - 4;
    8'bx1001xxx: bc <= (tran_length*4) - 2;
    8'bx10001xx: bc <= (tran_length*4) - 3;
    8'bx100001x: bc <= (tran_length*4) - 4;
    8'bx1000001: bc <= (tran_length*4) - 5;
    8'b10001xxx: bc <= (tran_length*4) - 3;
    8'b100001xx: bc <= (tran_length*4) - 4;
    8'b1000001x: bc <= (tran_length*4) - 5;
    8'b10000001: bc <= (tran_length*4) - 6;
    endcase
  
  
    // implementation of table 2-22 from PCIe base spec
    //tran_be = first, last
    casex(tran_be[7:4])
    4'b0000: la <= {tran_addr, 2'b00};     
    4'bxxx1: la <= {tran_addr, 2'b00};     
    4'bxx10: la <= {tran_addr, 2'b01};     
    4'bx100: la <= {tran_addr, 2'b10};     
    4'b1000: la <= {tran_addr, 2'b11};     
    endcase

  end //clk
end
endmodule

[Lattice User (Gast)]

Wo kommt "rx_din" her? wenn es einfach rx_din vom PCIe core ist, kann es 
nicht gehen. Der Wert den du da abfragen willst, liegt da schon seit 
vielen Takten nicht mehr an.

[Keller T. (fabito)]

Schau Mal ganz unten dem folgende Module. Ich habe einfach rx_din 
hinzugefügt als neu input für das Module wb_tlc_cpld.
Es wäre vielleicht einfacher wenn man folgende Signale ausnutzen würde:

assign write = wb_cyc_o && (wb_we_o);
assign read = read_comp && (~ read_comp_d);

module wb_tlc (clk_125, wb_clk, rstn, 
               rx_data, rx_st, rx_end, rx_bar_hit,
               wb_adr_o, wb_dat_o, wb_cti_o, wb_we_o, wb_sel_o, wb_stb_o, wb_cyc_o, wb_lock_o, 
               wb_dat_i, wb_ack_i,
               pd_cr, ph_cr, pd_num, npd_cr, nph_cr,               
               tx_rdy, tx_ca_cpl_recheck, tx_ca_cplh, tx_ca_cpld,
               tx_req, tx_data, tx_st, tx_end, 
               comp_id,
               debug
);
                    
input clk_125;
input wb_clk;
input rstn;

input [15:0] rx_data;
input rx_st;
input rx_end;
input [6:0] rx_bar_hit;

output [31:0] wb_adr_o;
output [15:0] wb_dat_o;
output [2:0] wb_cti_o;
output wb_we_o;
output [1:0] wb_sel_o;
output wb_stb_o;
output wb_cyc_o;
output wb_lock_o;
input wb_ack_i;
input [15:0] wb_dat_i;

output pd_cr, ph_cr, npd_cr, nph_cr;
output [7:0] pd_num;
input tx_rdy;
output tx_req;
output [15:0] tx_data;
output tx_st;
output tx_end;
input  tx_ca_cpl_recheck;
input  [8:0] tx_ca_cplh;
input  [12:0] tx_ca_cpld;
input [15:0] comp_id; // completer id = {bus_num, dev_num, func_num}

output [31:0] debug;

wire [15:0] to_req_fifo_dout;
wire to_req_fifo_sop;
wire to_req_fifo_eop;
wire to_req_fifo_dwen;
wire to_req_fifo_wrn;
wire to_req_fifo_wen;
wire [6:0] to_req_fifo_bar;

wire [15:0] from_req_fifo_dout;
wire from_req_fifo_sop;
wire from_req_fifo_eop;
wire from_req_fifo_wrn;
wire tlp_avail;

wire [15:0] read_data;
wire [9:0] tran_len;
wire [23:0] tran_id;
wire [7:0] tran_be;
wire [4:0] tran_addr;
wire [2:0] tran_tc;
wire [1:0] tran_attr;


wire [15:0] cmpl_d;
wire [6:0] from_req_fifo_bar;

reg ph_cr_wb;
reg [7:0] pd_num_wb;
reg read_comp_d;
reg [7:0] pd_num;
wb_tlc_dec #(.c_DATA_WIDTH (16)) dec(.clk_125(clk_125), .rstn(rstn),
               .rx_din(rx_data), .rx_sop(rx_st), .rx_eop(rx_end), .rx_dwen(1'b0), .rx_bar_hit(rx_bar_hit),
               .fifo_dout(to_req_fifo_dout), .fifo_sop(to_req_fifo_sop), .fifo_eop(to_req_fifo_eop),  
               .fifo_dwen(to_req_fifo_dwen), .fifo_wrn(to_req_fifo_wrn), .fifo_wen(to_req_fifo_wen),
               .fifo_bar(to_req_fifo_bar)
);                                           

wb_tlc_req_fifo #(.c_DATA_WIDTH (16)) req_fifo (.rstn(rstn), .clk_125(clk_125), .wb_clk(wb_clk),
                    .din(to_req_fifo_dout), .din_bar(to_req_fifo_bar), .din_sop(to_req_fifo_sop), .din_eop(to_req_fifo_eop), 
                    .din_wrn(to_req_fifo_wrn),.din_dwen(1'b0), .din_wen(to_req_fifo_wen), 
                    .dout(from_req_fifo_dout), .dout_sop(from_req_fifo_sop), .dout_eop(from_req_fifo_eop), .dout_wrn(from_req_fifo_wrn), 
                    .dout_bar(from_req_fifo_bar), .dout_dwen(),
                    .dout_ren(to_req_fifo_ren), .tlp_avail(tlp_avail)
                    
);

always @(posedge wb_clk or negedge rstn)
   if (!rstn) begin
      ph_cr_wb <= 0;
      pd_num_wb <= 8'd1;
   end
   else begin
      ph_cr_wb <= from_req_fifo_sop & from_req_fifo_wrn;
      if (ph_cr_wb)
         pd_num_wb <= (from_req_fifo_dout[1:0] == 2'b00) ? from_req_fifo_dout[9:2] : (from_req_fifo_dout[9:2] + 1);
   end

wb_tlc_cr phcr(.rstn(rstn), .clk_125(clk_125), .wb_clk(wb_clk), .cr_wb(ph_cr_wb), .cr_125(ph_cr));
assign pd_cr = ph_cr;          

always @(posedge clk_125 or negedge rstn)
   if (!rstn)
      pd_num <= 8'd1;
   else
      pd_num <= pd_num_wb;
      





wb_intf intf (.rstn(rstn), .wb_clk(wb_clk), 
               .din(from_req_fifo_dout), .din_sop(from_req_fifo_sop), .din_eop(from_req_fifo_eop), 
               .din_bar(from_req_fifo_bar), .din_wrn(from_req_fifo_wrn),
               .din_ren(to_req_fifo_ren), .tlp_avail(tlp_avail),
               .tran_id(tran_id), .tran_length(tran_len), .tran_be(tran_be), .tran_addr(tran_addr), .tran_tc(tran_tc), .tran_attr(tran_attr),
               .wb_adr_o(wb_adr_o), .wb_dat_o(wb_dat_o), .wb_cti_o(wb_cti_o), .wb_we_o(wb_we_o), .wb_sel_o(wb_sel_o), .wb_stb_o(wb_stb_o), .wb_cyc_o(wb_cyc_o), .wb_lock_o(wb_lock_o), .wb_ack_i(wb_ack_i)                              
);              


assign read_data = {wb_dat_i[7:0], wb_dat_i[15:8]}; // order bytes back to PCIe order

assign read_comp = wb_cyc_o && (~ wb_we_o);
assign write = wb_cyc_o && (wb_we_o);
assign read = read_comp && (~ read_comp_d);

always @(posedge wb_clk or negedge rstn)
   if (!rstn) begin
      read_comp_d <= 0;
   end
   else begin
      read_comp_d <= read_comp;
   end

wb_tlc_cpld  cpld (.wb_clk(wb_clk), .rstn(rstn),.rx_din(rx_data),
                .din(read_data), .sel(wb_sel_o), .read(read), .valid(wb_ack_i),
                .tran_id(tran_id), .tran_length(tran_len), .tran_be(tran_be), .tran_addr(tran_addr), .tran_tc(tran_tc), .tran_attr(tran_attr), .comp_id(comp_id),
                .dout(cmpl_d), .dout_sop(cmpl_sop), .dout_eop(cmpl_eop),  .dout_wen(cmpl_wen)                
);


wb_tlc_cpld_fifo #(.c_DATA_WIDTH (16)) cpld_fifo(.rstn(rstn), .clk_125(clk_125), .wb_clk(wb_clk),
                    .din(cmpl_d), .din_sop(cmpl_sop), .din_eop(cmpl_eop),  .din_dwen(1'b0), .din_wen(cmpl_wen),                  
                    .tx_data(tx_data), .tx_st(tx_st), .tx_end(tx_end), .tx_dwen(),  .tx_ca_cpl_recheck(tx_ca_cpl_recheck), .tx_ca_cplh(tx_ca_cplh), .tx_ca_cpld(tx_ca_cpld),
                    .tx_rdy(tx_rdy), .tx_req(tx_req)
); 

assign nph_cr = tx_st;
assign npd_cr = 1'b0;

endmodule

[Keller T. (fabito)]

Hallo hier einen Hinweis zu la Signal:(2.2.9 Completion Rules im PCIe 
Specification 2.1)
Damit muss man la =0
• Lower Address[6:0] – lower byte address for starting byte of 
Completion
♦ For Memory Read Completions, the value in this field is the byte 
address for the first
enabled byte of data returned with the Completion (see the rules in 
Section 2.3.1.1)
♦ For AtomicOp Completions, the Lower Address field is reserved.
5 ♦ This field is set to all 0’s for all remaining types of Completions. 
Receivers may
optionally check for violations of this rule. See Section 2.3.2, second 
bullet, for details.

Ich habe auch dies aus von Xilinx Completion Module (Sieh unten)

procedure PROC_TX_COMPLETION (
 
  tag                      : in std_logic_vector (7 downto 0);
  tc                       : in std_logic_vector (2 downto 0);
  len                      : in std_logic_vector (9 downto 0);
  comp_status              : in std_logic_vector (2 downto 0);
  signal trn_td_c          : out std_logic_vector(63 downto 0);
  signal trn_tsof_n        : out std_logic;
  signal trn_teof_n        : out std_logic;
  signal trn_trem_n_c      : out std_logic_vector(7 downto 0);
  signal trn_tsrc_rdy_n    : out std_logic;
  signal trn_lnk_up_n : in std_logic;
  signal trn_tdst_rdy_n : in std_logic;
  signal trn_clk : in std_logic
 
) is
 
begin
 
  assert (trn_lnk_up_n = '0')
  report "TX Trn interface is MIA"
    severity failure;
 
 
  PROC_TX_SYNCHRONIZE(0, 0, trn_lnk_up_n, trn_tdst_rdy_n, trn_clk);
 
  trn_td_c          <= '0' &
                       "00" &
                       "01010" &
                       '0' &
                       tc(2 downto 0) &
                       "0000" &
                       '0' &
                       '0' &
                       "00" &
                       "00" &
                       len(9 downto 0) &
                       COMPLETER_ID_CFG &
                       comp_status(2 downto 0) &
                       '0' &
                       X"000";
  trn_tsof_n        <= '0';
  trn_teof_n        <= '1';
  trn_trem_n_c      <= X"00";
  trn_tsrc_rdy_n    <= '0';
 
  PROC_TX_SYNCHRONIZE(1,0, trn_lnk_up_n, trn_tdst_rdy_n, trn_clk);
 
  trn_td_c          <= COMPLETER_ID_CFG &
                       tag(7 downto 0) &
                       X"00" &
                       X"00000000";
  trn_tsof_n        <= '1';
  trn_teof_n        <= '0';
  trn_trem_n_c      <= X"0F";
 
  PROC_TX_SYNCHRONIZE(1, 1, trn_lnk_up_n, trn_tdst_rdy_n, trn_clk);
 
  trn_teof_n        <= '1';
  trn_trem_n_c      <= X"00";
  trn_tsrc_rdy_n    <= '1';
 
 
end PROC_TX_COMPLETION;

[Lattice User (Gast)]

keller thomas schrieb:
> Schau Mal ganz unten dem folgende Module. Ich habe einfach rx_din
> hinzugefügt als neu input für das Module wb_tlc_cpld.

rx_din ist wie schon mehrfach gesagt ungeignet.
Du musst dir den ganzen Ablauf in Takten vor Augen halten, sonst wird 
das nichts mit deiner Zukunft als VHDL/Verilog Entwickler.

> Es wäre vielleicht einfacher wenn man folgende Signale ausnutzen würde:
>

> assign write = wb_cyc_o && (wb_we_o);
> assign read = read_comp && (~ read_comp_d);
>

Schon besser, aber beachte dass das write das dem cpld übergibst nur 
einen Takt lang sein sollte, (am Ende des WB Cycles)
Ausserdem ganz wichtig, wenn du es wie bei read nur aus den Whishbone 
signalen generierts, kannst du nicht zwischen Mem und IO Writes 
unterscheiden. Und bei Mem Writes darfst du keine Completions 
generieren.


keller thomas schrieb:
> Hallo hier einen Hinweis zu la Signal:(2.2.9 Completion Rules im PCIe
> Specification 2.1)
> Damit muss man la =0

Da bin ich mir nicht sicher, aber ich habe bislang keine Write 
Completions (IO bzw CFG) implementieren müssen, und damit das ganze auch 
nicht detailiert untersucht.
Leg dir einen PCIe Analyzer zu, dann kannst du schauen was bei CFG 
Writes gemacht wird.

[Keller T. (fabito)]

Hallo ,

Habe was festgestellt, beim Read aus MemoryMap Bereiche also BAR1 wird 
das Signal read gesetzt und Completion auch.
Aber beim Read aus IO-Bereiche wird das Signal Read niemals gesetzt.
Es scheint als es ein Filter irgendwo noch gibt der nur MWr/Mrd 
ermöglicht.
Schaue Mal bitte kurz die Bilder aus LogicAnalyser aus

[Lattice User (Gast)]

keller thomas schrieb:
> Hallo ,
>
> Habe was festgestellt, beim Read aus MemoryMap Bereiche also BAR1 wird
> das Signal read gesetzt und Completion auch.
> Aber beim Read aus IO-Bereiche wird das Signal Read niemals gesetzt.
> Es scheint als es ein Filter irgendwo noch gibt der nur MWr/Mrd
> ermöglicht.

Da es schon mal funktioniert hat, mit Backup bzw älterem Zustände aus 
der Versionsverwaltung vergleichen.

> Schaue Mal bitte kurz die Bilder aus LogicAnalyser aus

Um aus denen schlau zu werden, müsste ich mich mit allen Details der 
Implementation beschäftigen. Dazu habe ich keine Zeit. Davon abgesehen
ist der Ausschnutt zu kurz: Wo ist der empfangene Request?

(Ich habe einen eigenen Wrapper und verwende nicht den von Lattice).

[Keller T. (fabito)]

Hallo Hier ein voll Ausschnutt (Request+ Completion)

Bei IO-Read TLP wird die richtige Wert gelesen (cpld_fifo/din = 
cpld/dout = 0x0303)ohne Header. Read Signal wird niemals gesetzt obwohl 
die richtige Data zuruckkommen.

Bei Memory-Read wird 0xFF00 mit entprechende Header gelesen als 
Completion.

Hat diese vielleicht mit meinen ip_rx_crpr.v und UR_gen.v Module?

Auf Hinweis werde ich denkbar da, ich seit 1 Woche daran arbeite.

[Keller T. (fabito)]

Zusammengefasst unten Linux Ausgabe:

Beim IO-Read wird 0x03 an die Adresse 0x4000 gelesen

und

Beim Memory-Read wird 0xFF an die Adresse 0x106004 gelesen

[Keller T. (fabito)]

Bei IO-Read bleibt der Counter ( word_cnt ) vom cpld.v Module bei 0 aber 
trotzdem wird die richtige Daten gelesen.
Und beim IO-Write bleibt der Counter immerhin bei 0

case (sm)
    IDLE:
    begin
      word_cnt <= 0;
      dout_eop <= 1'b0;
      if (read) begin
         sm <= ACK; 
         dout_sop <= 1'b1;
         dout_wen <= 1'b1;
         dout <= {8'h4a, 1'b0, tran_tc, 4'd0};
         end
    else if ((~read) && (rx_din[15:8]== 8'b01x0_0010))begin
         sm <= ACK; 
         dout_sop <= 1'b1;
         dout_wen <= 1'b1;
         dout <= {8'h0a, 1'b0, tran_tc, 4'd0};
         end
    end
    ACK: // write header parts
    begin
      dout_wen <= 1'b1;
      dout_sop <= 1'b0;
       if (read) begin
    case (word_cnt)
         0: dout  <= {2'b00, tran_attr, 2'b00, tran_length};
         1: dout  <= comp_id; 
         2: dout  <= {3'b000, 1'b0, bc};
         3: dout  <= tran_id[23:8];
         4: dout  <= {tran_id[7:0], 1'b0, la};
      endcase
      end
    else if ((~read) && (rx_din[15:8]== 8'b01x0_0010))begin
    case (word_cnt)
         0: dout  <= {2'b00, tran_attr, 2'b00, 10'd0};
         1: dout  <= comp_id; 
         2: dout  <= {3'b000, 1'b0, 12'd4}; // 16'b
         3: dout  <= tran_id[23:8];
         4: dout  <= {tran_id[7:0], 1'b0, la};
      endcase
    end
    
      if (word_cnt == 4) begin
     if ((~read) && (rx_din[15:8]== 8'b01x0_0010))begin
      dout_eop <= 1'b1;
          sm <= CLEAR;
          end
     else begin
     sm <= DAT;
         word_cnt <= 1;
         end
     end
     else
        word_cnt <= word_cnt + 1;
    end
    DAT: // write data parts
    begin
      dout_wen <= valid_p5;
      dout <= din_p5;
      if (valid_p5) begin
         if (word_cnt == {tran_length, 1'b0}) begin
            dout_eop <= 1'b1;
            sm <= CLEAR;
         end
         else
            word_cnt <= word_cnt + 1;
      end
    end    
    CLEAR: // clean up  
    begin
      dout_wen <= 1'b0;      
      dout_eop <= 1'b0;      
      sm <= IDLE;
    end
    
    endcase

Dann lässt sich die Frage stellen Warum ? Wie soll ich ihm erzwingen 
rein zu gehen ? Es gibt meiner Meinung nach eine Zeilecode wo nur Memory 
Requests erlauben werden.
Auf Hinweise würde ich mich freuen

[Keller T. (fabito)]

Ich hätte erwartet dass, das read Signale beim IO-Read zu 1 geht .
Mein naschter Schritt ist der Grund zu verstehen oder ?

[Lattice User (Gast)]

keller thomas schrieb:
> Ich hätte erwartet dass, das read Signale beim IO-Read zu 1 geht .
> Mein naschter Schritt ist der Grund zu verstehen oder ?

Offensichtlich wird in wb_intf der IORead nicht erkannt

[Keller T. (fabito)]

Hallo,

Ich habe aus ein ECP3 PCI Express Basic Demo Design mein Design 
abgeleitet(also MMAP basiert ohne IO).
Beim Test lauft alles gut bis etwa 8 Stunden und bleibt hangen.
Ist dies ein Hardware Timer oder Timing Constrainsts ?
beigefügt is mein Place_Route_Trace_Report zu finden.

Auf Anmerkungen würde ich mich freuen..

[Lattice User (Gast)]

keller thomas schrieb:

> Beim Test lauft alles gut bis etwa 8 Stunden und bleibt hangen.

Hört sich nach fehlender PCI Express Lizens an. (Eval Timer)

Disable mal in den Strategy Settings unter Translate Design die Hardware 
Evaluation.

[Keller T. (fabito)]

Eigentlich habe ich eine Lizenz. Nur habe ich mein Design vom 
ReferenzDesign danach zusatzliche Komponente addiert.

Wie komme ich drauf also unter welche Menu (Sieh Bild)

[Keller T. (fabito)]

Hallo,

Unter Project/Active Strategy/Translate Design Setting habe ich 
folgende:

Name                   Type      Value
Hardware Evaluation    List      Enable

Was soll ich denn hier ändern durch was ??

[Keller T. (fabito)]

OK habe ich es Disable

Nun teste ich wieder .........

[Keller T. (fabito)]

Hallo,

Nach der Änderung
Hardware Evaluation    List      Disable

Habe ich während der neuen Kopilierung folgende Meldung erhalten:

Your License has expired.

Feature has expired.
Feature: LSC_IP_pcie_x1_e3_ipe
Expired date 16-jan-2013

Danach bleibt meine Kompilierung hängen.Somit ist mir klar dass, es um 
eine Lizenz Problem geht oder ?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

keller thomas schrieb:
> Your License has expired.
> Somit ist mir klar dass, es um eine Lizenz Problem geht oder ?
Sieht wohl so aus...

Die Lizenz des Versa-Kits gilt nur für 1 Jahr. Dann musst du dir ein 
neues Kit kaufen... ;-)

[Lattice User (Gast)]

Lothar Miller schrieb:
> keller thomas schrieb:
>> Your License has expired.
>> Somit ist mir klar dass, es um eine Lizenz Problem geht oder ?
> Sieht wohl so aus...
>
> Die Lizenz des Versa-Kits gilt nur für 1 Jahr. Dann musst du dir ein
> neues Kit kaufen... ;-)

Für Diamond selbst hat er ja eine gültige Versa-spezifische Lizenz, die 
freie Weblizenz gilt normalerweise nicht für die ECP3.

Also einfach mal nachfragen.

Auch bei der Verlängerung regulären Volllizenz für Diamond, muss man die 
IP Lizenzen jedesmal manuell nachtragen lassen.