Lattice Diamond: UART Receiver Siganl Wegoptimiert

[Keller T. (fabito)]

Hallo zusammen,

Kann mir jemand sagen, wieso in Diamond1.3 die uart_srx_i Signal 
komplett wegoptimiert wird?

// $Id: top_basic.v,v 1.2 2008/07/02 19:10:29 jfreed Exp $


module top  (   
   rstn,
   FLIP_LANES, LED_INV,
   
    
   refclkp, refclkn,
   hdinp, hdinn,                   
   hdoutp, hdoutn, 

   pll_lk, poll, l0, dl_up, usr0, usr1, usr2, usr3,
 //  na_pll_lk, na_poll, na_l0, na_dl_up, na_usr0, na_usr1, na_usr2, na_usr3,   // cngd frm org
   dip_switch,  uart_srx_i, led_out, dp
   );

input rstn;
input refclkp, refclkn;
input hdinp, hdinn;
output hdoutp, hdoutn;

// These two inputs are set in the .lpf file
input FLIP_LANES; // Flip PCIe lanes
input LED_INV;  // LED polarity inverted


output pll_lk, poll, l0, dl_up, usr0, usr1, usr2, usr3;
         // na_pll_lk, na_poll, na_l0, na_dl_up, na_usr0, na_usr1, na_usr2, na_usr3;   // cngd frm org
input [7:0] dip_switch;
output [13:0] led_out; // cngd frm org
output dp;
//output [15:0] TP;
//output [33:0] la;// cngd frm org
output uart_stx_o;
input uart_srx_i;

reg  [19:0] rstn_cnt;
reg  core_rst_n;
wire [13:0] led_out_int;

wire [3:0]               phy_ltssm_state; 
wire dl_up_int;

wire [15:0] rx_data, tx_data,  tx_dout_wbm, tx_dout_ur;
wire [6:0] rx_bar_hit;

wire [7:0] pd_num, pd_num_ur, pd_num_wb;

wire [15:0] pcie_dat_i, pcie_dat_o;
wire [31:0] pcie_adr;
wire [1:0] pcie_sel;  
wire [2:0] pcie_cti;
wire pcie_cyc;
wire pcie_we;
wire pcie_stb;
wire pcie_ack;


//------------ GPIO
wire [15:0] gpio_dat_i, gpio_dat_o;
wire [31:0] gpio_adr;
wire [1:0] gpio_sel;
wire [2:0] gpio_cti;
wire gpio_cyc;
wire gpio_we;
wire gpio_stb;
wire gpio_ack;

//------------ UART
wire [15:0] uart_dat_i, uart_dat_o;
wire [31:0] uart_adr;
wire [1:0] uart_sel;
wire [2:0] uart_cti;
wire uart_cyc;
wire uart_we;
wire uart_stb;
wire uart_ack;

//------------ EBR
wire [15:0] ebr_dat_i, ebr_dat_o;
wire [31:0] ebr_adr;
wire [1:0] ebr_sel;
wire [2:0] ebr_cti;
wire ebr_cyc;
wire ebr_we;
wire ebr_stb;
wire ebr_ack;

wire [7:0] bus_num ; 
wire [4:0] dev_num ; 
wire [2:0] func_num ;


wire [8:0] tx_ca_ph ;
wire [12:0] tx_ca_pd  ;
wire [8:0] tx_ca_nph ;
wire [12:0] tx_ca_npd ;
wire [8:0] tx_ca_cplh;
wire [12:0] tx_ca_cpld ;
wire clk_125;
wire tx_eop_wbm;
//=============================================================================
// Reset management
//=============================================================================
always @(posedge clk_125 or negedge rstn) begin
   if (!rstn) begin
       rstn_cnt   <= 20'd0 ;
       core_rst_n <= 1'b0 ;
   end
   else begin
      if (rstn_cnt[19])            // 4ms in real hardware
         core_rst_n <= 1'b1 ;
      // synthesis translate_off
         else if (rstn_cnt[7])     // 128 clocks 
            core_rst_n <= 1'b1 ;
      // synthesis translate_on
      else 
         rstn_cnt <= rstn_cnt + 1'b1 ;
   end
end
// LED Assignments
led_status led(.clk(clk_125), .rstn(core_rst_n), .invert(LED_INV),
        .lock(1'b1), .ltssm_state(phy_ltssm_state), .dl_up_in(dl_up_int), .bar1_hit(rx_bar_hit[1] | rx_bar_hit[0]),
        .pll_lk(pll_lk), .poll(poll), .l0(l0), .dl_up_out(dl_up), 
        .usr0(usr0), .usr1(usr1), .usr2(usr2), .usr3(usr3),
        .na_pll_lk(na_pll_lk), .na_poll(na_poll), .na_l0(na_l0), .na_dl_up_out(na_dl_up), 
        .na_usr0(na_usr0), .na_usr1(na_usr1), .na_usr2(na_usr2), .na_usr3(na_usr3), .dpn(dp)
);


pcie_top pcie(   
   .refclkp                    ( refclkp ),    
   .refclkn                    ( refclkn ),   
   .sys_clk_125                ( clk_125 ),
   .ext_reset_n                ( rstn ),
   .rstn                       ( core_rst_n ),    
   .flip_lanes                 ( FLIP_LANES ),
                               
   .hdinp0                     ( hdinp ), 
   .hdinn0                     ( hdinn ), 
   .hdoutp0                    ( hdoutp ), 
   .hdoutn0                    ( hdoutn ), 
                               
   .msi                        (  8'd0 ),
   .inta_n                     (  1'b1 ),
   
   // This PCIe interface uses dynamic IDs. 
   .vendor_id                  (16'h1204),       
   .device_id                  (16'hec30),       
   .rev_id                     (8'h00),          
   .class_code                 (24'h000000),      
   .subsys_ven_id              (16'h1204),   
   .subsys_id                  (16'h3010),       
   .load_id                    (1'b1),         
   
   
   // Inputs
   .force_lsm_active           ( 1'b0 ), 
   .force_rec_ei               ( 1'b0 ),     
   .force_phy_status           ( 1'b0 ), 
   .force_disable_scr          ( 1'b0 ),
                               
   .hl_snd_beacon              ( 1'b0 ),
   .hl_disable_scr             ( 1'b0 ),
   .hl_gto_dis                 ( 1'b0 ),
   .hl_gto_det                 ( 1'b0 ),
   .hl_gto_hrst                ( 1'b0 ),
   .hl_gto_l0stx               ( 1'b0 ),
   .hl_gto_l1                  ( 1'b0 ),
   .hl_gto_l2                  ( 1'b0 ),
   .hl_gto_l0stxfts            ( 1'b0 ),
   .hl_gto_lbk                 ( 1'd0 ),
   .hl_gto_rcvry               ( 1'b0 ),
   .hl_gto_cfg                 ( 1'b0 ),
   .no_pcie_train              ( 1'b0 ),    

   // Power Management Interface
   .tx_dllp_val                ( 2'd0 ),
   .tx_pmtype                  ( 3'd0 ),
   .tx_vsd_data                ( 24'd0 ),

   .tx_req_vc0                 ( tx_req ),    
   .tx_data_vc0                ( tx_data ),    
   .tx_st_vc0                  ( tx_st ), 
   .tx_end_vc0                 ( tx_end ), 
   .tx_nlfy_vc0                ( 1'b0 ), 
   .ph_buf_status_vc0       ( 1'b0 ),
   .pd_buf_status_vc0       ( 1'b0 ),
   .nph_buf_status_vc0      ( 1'b0 ),
   .npd_buf_status_vc0      ( 1'b0 ),
   .ph_processed_vc0        ( ph_cr ),
   .pd_processed_vc0        ( pd_cr ),
   .nph_processed_vc0       ( nph_cr ),
   .npd_processed_vc0       ( npd_cr ),
   .pd_num_vc0              ( pd_num ),
   .npd_num_vc0             ( 8'd1 ),   
   

   // From User logic
   .cmpln_tout                 ( 1'b0 ),       
   .cmpltr_abort_np            ( 1'b0 ),
   .cmpltr_abort_p             ( 1'b0 ),
   .unexp_cmpln                ( 1'b0 ),
   .ur_np_ext                  ( 1'b0 ),       
   .ur_p_ext                   ( 1'b0 ),
   .np_req_pend                ( 1'b0 ),     
   .pme_status                 ( 1'b0 ),      
         
   .tx_dllp_sent               (  ),
   .rxdp_pmd_type              (  ),
   .rxdp_vsd_data              (  ),
   .rxdp_dllp_val              (  ),
  
 
   .phy_ltssm_state            ( phy_ltssm_state ),     
   .phy_ltssm_substate         ( ),     
   .phy_pol_compliance         ( ),   

   .tx_rdy_vc0                 ( tx_rdy),  
   .tx_ca_ph_vc0               ( tx_ca_ph),
   .tx_ca_pd_vc0               ( tx_ca_pd),
   .tx_ca_nph_vc0              ( tx_ca_nph),
   .tx_ca_npd_vc0              ( tx_ca_npd ), 
   .tx_ca_cplh_vc0             ( tx_ca_cplh ),
   .tx_ca_cpld_vc0             ( tx_ca_cpld ),
   .tx_ca_p_recheck_vc0        ( tx_ca_p_recheck ),
   .tx_ca_cpl_recheck_vc0      ( tx_ca_cpl_recheck ),
   .rx_data_vc0                ( rx_data),    
   .rx_st_vc0                  ( rx_st),     
   .rx_end_vc0                 ( rx_end),   
   .rx_us_req_vc0              ( rx_us_req ), 
   .rx_malf_tlp_vc0            ( rx_malf_tlp ), 
   .rx_bar_hit                 ( rx_bar_hit ), 
   .mm_enable                  (  ),
   .msi_enable                 (  ),

   // From Config Registers
   .bus_num                    ( bus_num  ),           
   .dev_num                    ( dev_num  ),           
   .func_num                   ( func_num  ),  
   .pm_power_state             (  ) , 
   .pme_en                     (  ) , 
   .cmd_reg_out                (  ),
   .dev_cntl_out               (  ),  
   .lnk_cntl_out               (  ),  

   .tx_rbuf_empty              (  ),   // Transmit retry buffer is empty
   .tx_dllp_pend               (  ),    // DLPP is pending to be transmitted
   .rx_tlp_rcvd                (  ),     // Received a TLP   

   // Datal Link Control SM Status
   .dl_inactive                (  ),
   .dl_init                    (  ),
   .dl_active                  (  ),
   .dl_up                      ( dl_up_int )   
);
reg rx_st_d;
reg tx_st_d;
reg [15:0] tx_tlp_cnt;
reg [15:0] rx_tlp_cnt;
always @(posedge clk_125 or negedge core_rst_n)
   if (!core_rst_n) begin
      tx_st_d <= 0;
      rx_st_d <= 0;
      tx_tlp_cnt <= 0;
      rx_tlp_cnt <= 0;
   end
   else begin
      tx_st_d <= tx_st;
      rx_st_d <= rx_st;
      if (tx_st_d) tx_tlp_cnt <= tx_tlp_cnt + 1;
      if (rx_st_d) rx_tlp_cnt <= rx_tlp_cnt + 1;
         
   end

ip_rx_crpr cr (.clk(clk_125), .rstn(core_rst_n), .rx_bar_hit(rx_bar_hit),
               .rx_st(rx_st), .rx_end(rx_end), .rx_din(rx_data),
               .pd_cr(pd_cr_ur), .pd_num(pd_num_ur), .ph_cr(ph_cr_ur), .npd_cr(npd_cr_ur), .nph_cr(nph_cr_ur)               
);

ip_crpr_arb crarb(.clk(clk_125), .rstn(core_rst_n), 
            .pd_cr_0(pd_cr_ur), .pd_num_0(pd_num_ur), .ph_cr_0(ph_cr_ur), .npd_cr_0(npd_cr_ur), .nph_cr_0(nph_cr_ur),
            .pd_cr_1(pd_cr_wb), .pd_num_1(pd_num_wb), .ph_cr_1(ph_cr_wb), .npd_cr_1(1'b0), .nph_cr_1(nph_cr_wb),               
            .pd_cr(pd_cr), .pd_num(pd_num), .ph_cr(ph_cr), .npd_cr(npd_cr), .nph_cr(nph_cr)               
);

UR_gen ur (.clk(clk_125), .rstn(core_rst_n),  
            .rx_din(rx_data), .rx_sop(rx_st), .rx_eop(rx_end), .rx_us(rx_us_req), .rx_bar_hit(rx_bar_hit),
             .tx_rdy(tx_rdy_ur), .tx_ca_cpl_recheck(1'b0), .tx_ca_cplh(tx_ca_cplh),
             .tx_req(tx_req_ur), .tx_dout(tx_dout_ur), .tx_sop(tx_sop_ur), .tx_eop(tx_eop_ur),
             .comp_id({bus_num, dev_num, func_num})
);
         
ip_tx_arbiter #(.c_DATA_WIDTH (16))
           tx_arb(.clk(clk_125), .rstn(core_rst_n), .tx_val(1'b1),
                  .tx_req_0(tx_req_wbm), .tx_din_0(tx_dout_wbm), .tx_sop_0(tx_sop_wbm), .tx_eop_0(tx_eop_wbm), .tx_dwen_0(1'b0),                 
                  .tx_req_1(1'b0), .tx_din_1(16'd0), .tx_sop_1(1'b0), .tx_eop_1(1'b0), .tx_dwen_1(1'b0),
                  .tx_req_2(1'b0), .tx_din_2(16'd0), .tx_sop_2(1'b0), .tx_eop_2(1'b0), .tx_dwen_2(1'b0),
                  .tx_req_3(tx_req_ur), .tx_din_3(tx_dout_ur), .tx_sop_3(tx_sop_ur), .tx_eop_3(tx_eop_ur), .tx_dwen_3(1'b0),
                  .tx_rdy_0(tx_rdy_wbm), .tx_rdy_1(), .tx_rdy_2( ), .tx_rdy_3(tx_rdy_ur),
                  .tx_req(tx_req), .tx_dout(tx_data), .tx_sop(tx_st), .tx_eop(tx_end), .tx_dwen(),
                  .tx_rdy(tx_rdy)
                  
);                           

wb_tlc wb_tlc(.clk_125(clk_125), .wb_clk(clk_125), .rstn(core_rst_n),
              .rx_data(rx_data), .rx_st(rx_st), .rx_end(rx_end), .rx_bar_hit(rx_bar_hit),
              .wb_adr_o(pcie_adr), .wb_dat_o(pcie_dat_o), .wb_cti_o(pcie_cti), .wb_we_o(pcie_we), .wb_sel_o(pcie_sel), .wb_stb_o(pcie_stb), .wb_cyc_o(pcie_cyc), .wb_lock_o(), 
              .wb_dat_i(pcie_dat_i), .wb_ack_i(pcie_ack),
              .pd_cr(pd_cr_wb), .pd_num(pd_num_wb), .ph_cr(ph_cr_wb), .npd_cr(npd_cr_wb), .nph_cr(nph_cr_wb),
              .tx_rdy(tx_rdy_wbm),
              .tx_req(tx_req_wbm), .tx_data(tx_dout_wbm), .tx_st(tx_sop_wbm), .tx_end(tx_eop_wbm), .tx_ca_cpl_recheck(1'b0), .tx_ca_cplh(tx_ca_cplh), .tx_ca_cpld(tx_ca_cpld),
              .comp_id({bus_num, dev_num, func_num}),
              .debug()
);


wb_arb #(.c_DATA_WIDTH(16),
         .S0_BASE     (32'h0000), //GPIO
         .S1_BASE     (32'h4000), // UART
         .S2_BASE     (32'h1000), //EBR
         .S3_BASE     (32'h5000)
) wb_arb (
    .clk(clk_125),
    .rstn(core_rst_n),
  
    // PCIe Master 
    .m0_dat_i(pcie_dat_o), 
    .m0_dat_o(pcie_dat_i), 
    .m0_adr_i(pcie_adr),
    .m0_sel_i(pcie_sel), 
    .m0_we_i(pcie_we), 
    .m0_cyc_i(pcie_cyc),
    .m0_cti_i(pcie_cti),
    .m0_stb_i(pcie_stb), 
    .m0_ack_o(pcie_ack), 
    .m0_err_o(), 
    .m0_rty_o(), 
    
    // DMA Master  //  // not used
    .m1_dat_i(16'd0), 
    .m1_dat_o(), 
    .m1_adr_i(32'd0),
    .m1_sel_i(2'd0), 
    .m1_we_i( 1'b0), 
    .m1_cyc_i(1'b0),
    .m1_cti_i(3'd0),
    .m1_stb_i(1'b0), 
    .m1_ack_o(), 
    .m1_err_o(), 
    .m1_rty_o(),         

    // GPIO 32-bit
    .s0_dat_i(gpio_dat_o), 
    .s0_dat_o(gpio_dat_i), 
    .s0_adr_o(gpio_adr), 
    .s0_sel_o(gpio_sel), 
    .s0_we_o (gpio_we), 
    .s0_cyc_o(gpio_cyc),
    .s0_cti_o (gpio_cti),
    .s0_stb_o(gpio_stb), 
    .s0_ack_i(gpio_ack), 
    .s0_err_i(gpio_err),
    .s0_rty_i(gpio_rty), 
    
    // UART Slave
    .s1_dat_i(uart_dat_o), 
    .s1_dat_o(uart_dat_i), 
    .s1_adr_o(uart_adr), 
    .s1_sel_o(uart_sel), 
    .s1_we_o (uart_we), 
    .s1_cyc_o(uart_cyc),
    .s1_cti_o(uart_cti),
    .s1_stb_o(uart_stb), 
    .s1_ack_i(uart_ack), 
    .s1_err_i(1'b0),
    .s1_rty_i(1'b0),
    
    // EBR
    .s2_dat_i(ebr_dat_o), 
    .s2_dat_o(ebr_dat_i), 
    .s2_adr_o(ebr_adr), 
    .s2_sel_o(ebr_sel), 
    .s2_we_o (ebr_we), 
    .s2_cyc_o(ebr_cyc),
    .s2_cti_o(ebr_cti),
    .s2_stb_o(ebr_stb), 
    .s2_ack_i(ebr_ack), 
    .s2_err_i(ebr_err),
    .s2_rty_i(ebr_rty),
    
    // Not used
    .s3_dat_i(16'd0), 
    .s3_dat_o(), 
    .s3_adr_o(), 
    .s3_sel_o(), 
    .s3_we_o (), 
    .s3_cyc_o(),
    .s3_cti_o(),
    .s3_stb_o(), 
    .s3_ack_i(1'b0),
    .s3_rty_i(1'b0), 
    .s3_err_i(1'b0)
);


             
wbs_gpio gpio(.wb_clk_i(clk_125), .wb_rst_i(~core_rst_n),
          .wb_dat_i(gpio_dat_i), .wb_adr_i(gpio_adr[8:0]), .wb_cti_i(gpio_cti), .wb_cyc_i(gpio_cyc), .wb_lock_i(1'b0), .wb_sel_i(gpio_sel), .wb_stb_i(gpio_stb), .wb_we_i(gpio_we),          
          .wb_dat_o(gpio_dat_o), .wb_ack_o(gpio_ack), .wb_err_o(gpio_err), .wb_rty_o(gpio_rty), 
          .switch_in(dip_switch), .led_out(led_out_int), 
          .dma_req(dma_req_gpio), .dma_ack(5'd0), 
          .ca_pd(tx_ca_pd), .ca_nph(tx_ca_nph), .dl_up(dl_up_int),
          .int_out()
);
assign led_out = ~led_out_int[13:0];          


wbs_uart uart(
      //wishbone signals
      .wb_clk_i(clk_125), 
      .wb_rst_i(~core_rst_n),
          .wb_dat_i(uart_dat_i), 
      .wb_adr_i(uart_adr), 
      .wb_cti_i(uart_cti), 
      .wb_cyc_i(uart_cyc), 
      .wb_lock_i(1'b0), 
      .wb_sel_i(uart_sel), .wb_stb_i(uart_stb), .wb_we_i(uart_we),          
          .wb_dat_o(uart_dat_o), .wb_ack_o(uart_ack), 
      .wb_err_o(uart_err), 
      .wb_rty_o(uart_rty), 
      
      //uart signals
      .stx_pad_o(), 
      .srx_pad_i(uart_srx_i), 

      //modem signals
      //.rts_pad_o(), .cts_pad_i(), .dtr_pad_o(), .dsr_pad_i(), .ri_pad_i(), .dcd_pad_i(),

      //interrupt
          .wb_int_o(int)
);


wbs_32kebr ebr(.wb_clk_i(clk_125), .wb_rst_i(~core_rst_n),
          .wb_dat_i(ebr_dat_i), .wb_adr_i(ebr_adr), .wb_cyc_i(ebr_cyc), .wb_sel_i(ebr_sel), .wb_stb_i(ebr_stb), .wb_we_i(ebr_we), .wb_cti_i(ebr_cti),
          .wb_dat_o(ebr_dat_o), .wb_ack_o(ebr_ack), .wb_err_o(ebr_err), .wb_rty_o(ebr_rty)          
);                          
  


// DEBUG OUPUT OPTIONS
//assign la = 34'd0; // cngd frm org
//assign TP = 16'd0;
                  
                



endmodule

Grüsse,
Henry

[Lattice User (Gast)]

Wo hast du wbs_uart her?

[Keller T. (fabito)]

Hallo,

Ich habe den Grund herausgefunden.

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

Ngii Rayan schrieb:
> Ich habe den Grund herausgefunden.
Schön.
Aber viel schöner wäre es, wenn du auch noch schreiben würdest, WAS es 
war. Immerhin könnte dein Wissen jemand Anderem später mal 
weiterhelfen...

[Keller T. (fabito)]

Hallo,

Das Problem lag an Wishbone Arbiter.Also einfach UART als Slave 0 wird 
es gelöst:

    // UART Slave
    .s0_dat_i(uart_dat_o),
    .s0_dat_o(uart_dat_i),
    .s0_adr_o(uart_adr),
    .s0_sel_o(uart_sel),
    .s0_we_o (uart_we),
    .s0_cyc_o(uart_cyc),
    .s0_cti_o(uart_cti),
    .s0_stb_o(uart_stb),
    .s0_ack_i(uart_ack),
    .s0_err_i(1'b0),
    .s0_rty_i(1'b0),

[Lattice User (Gast)]

Ngii Rayan schrieb:
> Das Problem lag an Wishbone Arbiter.Also einfach UART als Slave 0 wird
> es gelöst:

Falsche Lösung, denn das Problem wird wieder auftauchen.

Ich habe mit den Arbiter angeschaut, die Slave Addressen müssen in 
aufsteigender Reihenfolge sein.

z.B:

         .S0_BASE     (32'h0000), //GPIO
         .S1_BASE     (32'h0800), // UART
         .S2_BASE     (32'h1000), //EBR
         .S3_BASE     (32'h5000)

[Keller T. (fabito)]

Ich gebe dir Recht!
Stimmt tauscht das Problem wieder bei mehrere Komponente. Nur wollte ich 
in meinem Fall nur UART Komponent testen.
Aber gilt deine Lösung allgemein für mehrere Komponente.

[Keller T. (fabito)]

Ich habe gerade deine Lösung getestet.
Leider tauscht wieder das Problem aus.

wb_arb #(.c_DATA_WIDTH(16),
         .S0_BASE     (32'h0000), // UART Slave
         .S1_BASE     (32'h0800), // GPIO
         .S2_BASE     (32'h1000), //EBR
         .S3_BASE     (32'h5000)
) wb_arb (
    .clk(clk_125),
    .rstn(core_rst_n),
  
    // PCIe Master 
    .m0_dat_i(pcie_dat_o), 
    .m0_dat_o(pcie_dat_i), 
    .m0_adr_i(pcie_adr),
    .m0_sel_i(pcie_sel), 
    .m0_we_i(pcie_we), 
    .m0_cyc_i(pcie_cyc),
    .m0_cti_i(pcie_cti),
    .m0_stb_i(pcie_stb), 
    .m0_ack_o(pcie_ack), 
    .m0_err_o(), 
    .m0_rty_o(), 
    
    // DMA Master  //  // not used
    .m1_dat_i(16'd0), 
    .m1_dat_o(), 
    .m1_adr_i(32'd0),
    .m1_sel_i(2'd0), 
    .m1_we_i( 1'b0), 
    .m1_cyc_i(1'b0),
    .m1_cti_i(3'd0),
    .m1_stb_i(1'b0), 
    .m1_ack_o(), 
    .m1_err_o(), 
    .m1_rty_o(),         

    // GPIO 32-bit
    .s1_dat_i(gpio_dat_o), 
    .s1_dat_o(gpio_dat_i), 
    .s1_adr_o(gpio_adr), 
    .s1_sel_o(gpio_sel), 
    .s1_we_o (gpio_we), 
    .s1_cyc_o(gpio_cyc),
    .s1_cti_o (gpio_cti),
    .s1_stb_o(gpio_stb), 
    .s1_ack_i(gpio_ack), 
    .s1_err_i(gpio_err),
    .s1_rty_i(gpio_rty), 
    
    // UART Slave
    .s0_dat_i(uart_dat_o), 
    .s0_dat_o(uart_dat_i), 
    .s0_adr_o(uart_adr), 
    .s0_sel_o(uart_sel), 
    .s0_we_o (uart_we), 
    .s0_cyc_o(uart_cyc),
    .s0_cti_o(uart_cti),
    .s0_stb_o(uart_stb), 
    .s0_ack_i(uart_ack), 
    .s0_err_i(1'b0),
    .s0_rty_i(1'b0),
    
    // EBR
    .s2_dat_i(ebr_dat_o), 
    .s2_dat_o(ebr_dat_i), 
    .s2_adr_o(ebr_adr), 
    .s2_sel_o(ebr_sel), 
    .s2_we_o (ebr_we), 
    .s2_cyc_o(ebr_cyc),
    .s2_cti_o(ebr_cti),
    .s2_stb_o(ebr_stb), 
    .s2_ack_i(ebr_ack), 
    .s2_err_i(ebr_err),
    .s2_rty_i(ebr_rty),
);

Es fehlt noch etwas damit alles 100% klappt

[Lattice User (Gast)]

Ngii Rayan schrieb:
> Es fehlt noch etwas damit alles 100% klappt

Mein Fehler, habe übersehen dass der Arbiter nur Adr[31:12] vergleicht.

Also:

         .S0_BASE     (32'h0000), //GPIO
         .S1_BASE     (32'h1000), // UART
         .S2_BASE     (32'h2000), //EBR
         .S3_BASE     (32'h5000)

[Keller T. (fabito)]

Genau das meinte ich !

Nun zum UART Test unter Linux: Hat jemand eine Idee warum ich meine GPIO 
Problemlos schreiben/lesen kann aber nicht meine UART Komponent?

[root@localhost pci_sample_2]# ./regrw ECP3_SFIF_1
User Space Lattice PCIe device driver using mmap
Board ECP3_SFIF_1
Opening access to lscpcie/ECP3_SFIF_1
fd = 2
pmem=0xb77eb000
*p0 = b77eb000  

Register Read/Write Access
r - read a 32 bit register
w - write a 32 bit value into a register
addresses are on 4 byte boundaries
q,x - exit
r|w <addr> [data]: w 0008 0000ffff     // ON LEDs 
r|w <addr> [data]: r 0008 0000ffff
00000008: 0xffff
r|w <addr> [data]: w 0008 00000000    // OFF LEDs

Aber das gleiche Verfahren kalppt nicht zum UART Zugriff:
Also

r|w <addr> [data]: w 1010 0000ffff     // UART Write to IER Register
r|w <addr> [data]: r 1000 0000ffff 
00001010:0x0                           // adress 1000: Rx/Tx Register

bin ich auf dem falschen Weg oder wie?

[Lattice User (Gast)]

Ich muss nochmal fragen, wo hast du wbs_uart her? Selbstgemacht?
Im Versakit, von dem du den toplevel wohl her hast, ist es jedenfalls 
nicht enthalten.

[Keller T. (fabito)]

Ja !

wbs_uart.v entpricht einfach uart_top.v von Opencore was ich mit Lattice 
Mico32 erfolgsreich getestet habe.
Also habe ich nur die toplevel Dateiename umbennant zur klarheit für das 
gesamte Projekt.

[Lattice User (Gast)]

Ngii Rayan schrieb:
> wbs_uart.v entpricht einfach uart_top.v von Opencore was ich mit Lattice
> Mico32 erfolgsreich getestet habe.

Und welcher der vielen UARTS, die es dort gibt? Setze doch einfach mal 
einen Link.

Du hast natürlich die Unterschiede in der Addressierung und 
Datenbusbreite beachtet?

[Keller T. (fabito)]

Here ist der Link: http://opencores.org/project,uart16550

Unter uart_defines.v sind Data und Adress Breite definiert:

// remove comments to restore to use the new version with 8 data bit interface
// in 32bit-bus mode, the wb_sel_i signal is used to put data in correct place
// also, in 8-bit version there'll be no debugging features included
// CAUTION: doesn't work with current version of OR1200
//`define DATA_BUS_WIDTH_8

`ifdef DATA_BUS_WIDTH_8
 `define UART_ADDR_WIDTH 3
 `define UART_DATA_WIDTH 8
`else
 `define UART_ADDR_WIDTH 5
 `define UART_DATA_WIDTH 32
`endif

Mit LatticeMico System hat folgende zu Lattice Mico32 CPU geklappt:

[vhdl]
opencoreuart2 
 opencoreuart2( 
.wb_ADR_I(SHAREDBUS_ADR_I[31:0]),
.wb_DAT_I(opencoreuart2wb_DAT_I[31:0]),
.wb_DAT_O(opencoreuart2wb_DAT_O[31:0]),
.wb_SEL_I(opencoreuart2wb_SEL_I[3:0]),
.wb_WE_I(SHAREDBUS_WE_I),
.wb_ACK_O(opencoreuart2wb_ACK_O),
.wb_ERR_O(opencoreuart2wb_ERR_O),
.wb_RTY_O(opencoreuart2wb_RTY_O),
.wb_CTI_I(SHAREDBUS_CTI_I),
.wb_BTE_I(SHAREDBUS_BTE_I),
.wb_LOCK_I(SHAREDBUS_LOCK_I),
.wb_CYC_I(SHAREDBUS_CYC_I & opencoreuart2wb_en),
.wb_STB_I(SHAREDBUS_STB_I & opencoreuart2wb_en),
.srx_pad_i(opencoreuart2srx_pad_i),
.stx_pad_o(opencoreuart2stx_pad_o),
.wb_int_o(opencoreuart2wb_int_o),
.wb_clk_i(clk_i), .wb_rst_i(sys_reset));

Und nun versuche ich folgende

//------------ UART
wire [31:0] uart_dat_i, uart_dat_o;
wire [31:0] uart_adr;
wire [1:0] uart_sel;
wire [2:0] uart_cti;
wire uart_cyc;
wire uart_we;
wire uart_stb;
wire uart_ack;

.....

wbs_uart uart(
      //wishbone signals
      .wb_clk_i(clk_125), 
      .wb_rst_i(~core_rst_n),
          .wb_dat_i(uart_dat_i), 
      .wb_adr_i(uart_adr), 
      //.wb_cti_i(uart_cti), 
      .wb_cyc_i(uart_cyc), 
      //.wb_lock_i(1'b0), 
      .wb_sel_i(uart_sel), .wb_stb_i(uart_stb), .wb_we_i(uart_we),          
          .wb_dat_o(uart_dat_o), .wb_ack_o(uart_ack), 
      //.wb_err_o(uart_err), 
      //.wb_rty_o(uart_rty), 
      
      
      //uart signals
      .stx_pad_o(uart_stx_o), 
      .srx_pad_i(uart_srx_i), 

      //modem signals
      //.rts_pad_o(), .cts_pad_i(), .dtr_pad_o(), .dsr_pad_i(), .ri_pad_i(), .dcd_pad_i(),

      //interrupt
          .int_o(int)
);

[Lattice User (Gast)]

Das geht so nicht.

Dein WB Datenbus ist 16bit breit (im Gegensatz zum Mico32).

Vom PC werden bei PCIe immer 32bit Zugriffe durchgeführt, dabei sind die 
Addressbits 0 und 1 immer auf 0 und zu ignorieren. Byteauswahl erfolgt 
durch Byte enables.

Der wb_tlc (PCIe -> Wishbone) Module übersetzt JEDEN PCIe Zugriff in 
ZWEI Wishbone cycles, wobei die Adresse um 2 incrementiert wird. Dieses 
Verhalten muss in deinem Slave berücksichtigt werden.

Sowas schaut man sich natürlich am besten in einer Simulation an. Da 
aber das Aufsetzen und schreiben einer PCIe testbench nicht einfach ist, 
bietet sich als Alternative auch Reveal an.

[Keller T. (fabito)]

Ich habe einen ersten Experiment mit Reveal gemacht und sie sehr 
nutzlich aus.
Was mir noch unklar ist folgende:

Der wb_tlc (PCIe -> Wishbone) Module übersetzt JEDEN PCIe Zugriff in
ZWEI Wishbone cycles für wishbone Slaves.

Meine Meinung: Stimmt aber nur wenn es um einen 32 bit Daten 
Übertragung.

Das ist beispielweise der Fall beim Zugriff auf 32 bit GPIO Register 
(Versa) und Byteauswahl erfolgt  durch wb_sel_i[0/1], wobei die Adresse 
um 2 incrementiert wird.

.....
assign wb_dat_o = wb_dat_local;
.....

      9'h004: begin
         if (rd) wb_dat_local <= scratch_pad[15:0];
         else if (wr) begin
            scratch_pad[15:8] <= wb_sel_i[0] ? wb_dat_i[15:8] : scratch_pad[15:8];
            scratch_pad[7:0]  <= wb_sel_i[1] ? wb_dat_i[7:0]  : scratch_pad[7:0];
         end
      end
      9'h006: begin
         if (rd) wb_dat_local <= scratch_pad[31:16];
         else if (wr) begin
            scratch_pad[31:24] <= wb_sel_i[0] ? wb_dat_i[15:8] : scratch_pad[31:24];
            scratch_pad[23:16] <= wb_sel_i[1] ? wb_dat_i[7:0]  : scratch_pad[23:16];
         end
      end

Nun meine Frage wie wäre falls PCIe TLP nur 8 bits schreiben/lesen soll? 
(8/16 Slave Devices). Der wb_tlc (PCIe -> Wishbone) Module in diesem 
Fall nur wb_sel_i[0] braucht um es zu machen. Folglich keine Adresse 
incrementierung .

Das ist der Fall für Opencore UART/CAN die 8 Bit Daten sind .Was 
bedeutet jeder Register vom Host über TLP Packet mit 8 Bits 
lesbar/schreibar ist .

9'h000: begin // Transmit/Receive Register
         if (rd) wb_dat_local <= receiv_reg[7:0];
         else if (wr) begin
            transmit_reg[7:0] <= wb_dat_i[7:0];
         end
9'h001: begin // Interrupt Enable Register
         if (rd) wb_dat_local <= int_enable_reg[7:0];
         else if (wr) begin
            int_enable_reg[7:0] <= wb_dat_i[7:0];
         end
.....

oder bin ich falsh !

[Franke (Gast)]

siehe oben

>Vom PC werden bei PCIe immer 32bit Zugriffe durchgeführt

und das ist so...

[Lattice User (Gast)]

Ngii Rayan schrieb:
> Meine Meinung: Stimmt aber nur wenn es um einen 32 bit Daten
> Übertragung.

Meinungen zählen hier nicht. Im Versa Kit ist der wb_tlc in source form 
enthalten. Schau ihn dir an.
(die WB Schreibzyklen werden in wb_tlc/wb_intf.v Zeile 179-218 
generiert.)

Nochmal, es gibt KEINE 8bit TLPs. TLPs sind IMMER vielfache von 4 Bytes, 
auch
wenn die PC einen 8 bit Zugriff macht. Dafür gibt es die wb_sel Signale.


Das gleiche Problem hast du übrigens wenn du ein 8 bit Slave (OpenCan) 
an einen 32bit Master anschliesst (Mico32).

[Keller T. (fabito)]

OK !

Da bedeutet in Lattice Fall: TLP Daten max = 1 DW (allgemein PCIe bis 
1024 DW möglich)
also
Length = 0x001

und um die benotige Byte zu wissen werden First DW Byte Enables und Last 
DW Byte Enables gebraucht also

bei 32 bits Datentransfer :Last BE = 0x0 und First BE = 0xf(1111)

bei 16 bits Datentransfer :Last BE = 0x0 und First BE = 0x3 (0011)

bei 8 bits Datentransfer :Last BE = 0x0 und First BE = 0x1 (0001)


Nun zu 8 bit Slave (OpenCan) an einen 32bit Master anschliesst (Mico32):

 bei 8 bit Opencore UART (beinhaltet ein sel_i Signal )also wurde kein 
Problem fesgestellt.

 aber mit 8 bit Opencore CAN(beinhaltet kein sel_i Signal ):lässt sich 
Read/Write Operationen mit Mico32 ausführen .

  Dies Problem lässt sich mit ALTERA mit dem 8 Bit Befehl IOWR_8DIRECT 
lösen auch wenn NIOS 32 bit ist.

  Wie wird es nun ohne sel_i Signal von Opencore CAN gelöst oder gibt es 
eine Opencore CAN Variante mit sel_i Signale?

[Lattice User (Gast)]

Ngii Rayan schrieb:
> Da bedeutet in Lattice Fall: TLP Daten max = 1 DW (allgemein PCIe bis
> 1024 DW möglich)
> also
> Length = 0x001

Wenn ich es richtig sehe unterstützt wb_tlc auch längere TLP, es werden 
dann halt auch entsprechend viele WB Zyklen erzeugt.

Allerdings erzeugt die CPU in einem PC bei Memorymapped IO  nur TLPs mit 
max 4 Bytes Payload, eventuell verteilt auf 2 DW. (Siehe Bild 1).

Ein memcopy mit 16 bytes wird auf viele TLPs verteilt (Siehe Bild 2).

>
> und um die benotige Byte zu wissen werden First DW Byte Enables und Last
> DW Byte Enables gebraucht also
>
> bei 32 bits Datentransfer :Last BE = 0x0 und First BE = 0xf(1111)
>
> bei 16 bits Datentransfer :Last BE = 0x0 und First BE = 0x3 (0011)
>
> bei 8 bits Datentransfer :Last BE = 0x0 und First BE = 0x1 (0001)

Das gilt nur wenn die Addresse auf PC Seite ein vielfaches von 4 ist.
Siehe die angehängten Beispiele

>
>
> Nun zu 8 bit Slave (OpenCan) an einen 32bit Master anschliesst (Mico32):
>
>  bei 8 bit Opencore UART (beinhaltet ein sel_i Signal )also wurde kein
> Problem fesgestellt.
>
>  aber mit 8 bit Opencore CAN(beinhaltet kein sel_i Signal ):lässt sich
> Read/Write Operationen mit Mico32 ausführen .
>
>   Dies Problem lässt sich mit ALTERA mit dem 8 Bit Befehl IOWR_8DIRECT
> lösen auch wenn NIOS 32 bit ist.

Das sieht aus wie ein Macro, das die passenden Addressumrechnungen 
macht.


>
>   Wie wird es nun ohne sel_i Signal von Opencore CAN gelöst oder gibt es
> eine Opencore CAN Variante mit sel_i Signale?

Mach dir eine. Ist ja schliesslich Opensource.

Beim Mico32 ist das Problem vermutlich einfach zu lösen indem du doe 
Registeroffsets mit 4 multiplizierst.

[Lattice User (Gast)]

Das 2. Bild nochmal mit Spaltenüberschriften.

[Keller T. (fabito)]

Danke für Klarheit durch ein echtes Beispiel. ich werde davon lernen um 
weiter zu implementieren.
Das Buch PCIe Architechture habe ich aber
so dargestellt wie dieses Beipiel lernt man mehr auf einmal.

Danke nochmals

[Keller T. (fabito)]

Mit dem Offset *4 für Opencore CAN blokiert ab

OPENCORECAN_REGISTER(OPENCORECAN2_BASE_ADDRESS, CAN_ACCEPTANCE_MASK)= 
bMASK; Zeile.

Ursprungliche ALTERA Code sieh so aus:(Sieh Anhang für OWR_8DIRECT 
Beschreibung)

IOWR_8DIRECT(CAN_CONTROL_BASE, CAN_CONTROL_REG, 0x1F);
    IOWR_8DIRECT(CAN_CONTROL_BASE, CAN_ACCEPTANCE_CODE, bCODE);
    IOWR_8DIRECT(CAN_CONTROL_BASE, CAN_ACCEPTANCE_MASK, bMASK);
    IOWR_8DIRECT(CAN_CONTROL_BASE, CAN_BUSTIMING_0, bBTR0);
    IOWR_8DIRECT(CAN_CONTROL_BASE, CAN_BUSTIMING_1, bBTR1);
    IOWR_8DIRECT(CAN_CONTROL_BASE, CAN_CLK_DIVIDER, 0x05);
    // now switch to operating mode
    bTmp = IORD_8DIRECT(CAN_CONTROL_BASE, CAN_CONTROL_REG);
    bTmp = bTmp & 0xFE;
    IOWR_8DIRECT(CAN_CONTROL_BASE, CAN_CONTROL_REG, bTmp);

Habe ich Mal 4 pro Offset und Mico 32 blokiert ab 4 Zeile:

   
   // turn on reset mode
    OPENCORECAN_REGISTER(OPENCORECAN2_BASE_ADDRESS, CAN_CONTROL_REG)=0x1F;
    
    // set acceptance mask
    OPENCORECAN_REGISTER(OPENCORECAN2_BASE_ADDRESS, CAN_ACCEPTANCE_CODE)=bCODE;

    OPENCORECAN_REGISTER(OPENCORECAN2_BASE_ADDRESS, CAN_ACCEPTANCE_MASK)= bMASK;

   // set bus timing registers
    OPENCORECAN_REGISTER(OPENCORECAN2_BASE_ADDRESS, CAN_BUSTIMING_0)= bBTR0;

    OPENCORECAN_REGISTER(OPENCORECAN2_BASE_ADDRESS, CAN_BUSTIMING_1)= bBTR1;

    // set clock divider field 
    OPENCORECAN_REGISTER(OPENCORECAN2_BASE_ADDRESS, CAN_CLK_DIVIDER)=0x05; //0101

    // turn off reset mode : operating mode
    bTmp=OPENCORECAN_REGISTER(OPENCORECAN2_BASE_ADDRESS, CAN_CONTROL_REG);
    bTmp = bTmp & 0xFE;
    OPENCORECAN_REGISTER(OPENCORECAN2_BASE_ADDRESS, CAN_CONTROL_REG)=bTmp;

[Lattice User (Gast)]

Schau dir das ganze mit Reveal an, sonst wird das nichts.

[Keller T. (fabito)]

Hallo

Mit Reveal Analyser bin ich dabei die DatenZugriff (8/32 Bits) über 
Lattice Wishbone Interface (wb_tlc/wb_intf.v) zu analysieren:

Dafür habe ich 2 Slaves über PCIe gebunden(32 Bit und 8 Bit)

sind folgende Betrachtungen für die Analyse richtig ?

SLAVE 32 Bit wird folgende erwartet:
-------------------------------------
32 Bit Zugriff auf Slave = 2 Wishbone Cycles
  Cycle one = wb_sel_i[1:0]=11 also 16 Bit werden übertragen
  Cycle two =  wb_sel_i[1:0]=11 also 16 Bit werden Bit werden übertragen

16 Bit Zugriff auf Slave = 1 Wishbone Cycles
  Cycle one = wb_sel_i[1:0]=11 also 16 Bit
  Cycle two =  wb_sel_i[1:0]=00 kein Zugriff auf Slave da nur 16 Bit


8 Bit Zugriff auf Slave = 1 Wishbone Cycles
  Cycle one = wb_sel_i[1:0]=01 also 8 Bit
  Cycle two =  wb_sel_i[1:0]=00 kein Zugriff auf Slave da nur 8 Bits


BEI SLAVE 8 Bits wird folgende erwartet:
------------------------------------------
32 Bit Zugriff auf Slave = 4 Wishbone Cycles
  Cycle one = wb_sel_i[1:0]=01 also 8 Bit werden übertragen
  Cycle two =  wb_sel_i[1:0]=01 also 8 Bit werden Bit werden übertragen
  Cycle three = wb_sel_i[1:0]=01 also 8 Bit werden übertragen
  Cycle four =  wb_sel_i[1:0]=01 also 8 Bit werden Bit werden übertragen

16 Bit Zugriff auf Slave = 2 Wishbone Cycles
  Cycle one = wb_sel_i[1:0]=01 also 8 Bit werden übertragen
  Cycle two =  wb_sel_i[1:0]=01 also 8 Bit werden Bit werden übertragen


8 Bit Zugriff auf Slave = 1 Wishbone Cycles
  Cycle one = wb_sel_i[1:0]=01 also 8 Bit werden übertragen

[Lattice User (Gast)]

Ngii Rayan schrieb:
> sind folgende Betrachtungen für die Analyse richtig ?

Nein.
Du gehst immer noch davon auss, dass es bei WB einen Busbreitenkonverter 
gibt. Gibt es in dem Beispiel nicht, und hat sich vermutlich auch noch 
niemand die Mühe gemsaht einen zu schreiben.

Schau dir in Reveal einfach nur die WB Signale in deinem Toplevel an.

[Keller T. (fabito)]

OK hast du Recht gibt es nicht in meinem Besipiel.(Versa)
Nur möchte ich einen Opencore UART 8 Bit Breite dazu binden und Zugriff 
ermöglichen.

Wenn man aus folgenden GPIO 32 Bit Zugriff Beispiel geht. Wie soll den 
Zugriff auf UART 8 Bit implementiert werden mit Bezug wb_intf.v Module?
(Ich habe einiges erfolglos probiert.)

So dass die 2 Wishbone Cycles Verhalten in UART Slave berücksichtigt 
wird.

      9'h004: begin
         if (rd) wb_dat_local <= scratch_pad[15:0];
         else if (wr) begin
            scratch_pad[15:8] <= wb_sel_i[0] ? wb_dat_i[15:8] : scratch_pad[15:8];
            scratch_pad[7:0]  <= wb_sel_i[1] ? wb_dat_i[7:0]  : scratch_pad[7:0];
         end
      end
      9'h006: begin
         if (rd) wb_dat_local <= scratch_pad[31:16];
         else if (wr) begin
            scratch_pad[31:24] <= wb_sel_i[0] ? wb_dat_i[15:8] : scratch_pad[31:24];
            scratch_pad[23:16] <= wb_sel_i[1] ? wb_dat_i[7:0]  : scratch_pad[23:16];
         end
      end

Der wb_tlc (PCIe -> Wishbone) Module übersetzt JEDEN PCIe Zugriff in
ZWEI Wishbone cycles, wobei die Adresse um 2 incrementiert wird. Dieses
Verhalten muss in deinem Slave berücksichtigt werden.

[Duke Scarring (Gast)]

Ngii Rayan schrieb:
> Der wb_tlc (PCIe -> Wishbone) Module übersetzt JEDEN PCIe Zugriff in
> ZWEI Wishbone cycles, wobei die Adresse um 2 incrementiert wird. Dieses
> Verhalten muss in deinem Slave berücksichtigt werden.
Wie wäre es, wenn Du die überflüssigen Bits einfach ignorierst?
Das macht so ziemlich jeder Busteilnehmer, wenn die zu übertragende 
Bitbreite kleiner ist als die native Bitbreite des Bussystems.
Und es zwingt Dich auch niemand in Deinem IP-Core auf jede Adresse zu 
reagieren, oder?

Duke

[Keller T. (fabito)]

Ouahh !

Ich bin mit dem Thema einen Schritt weiter. Ich habe ein GPIO Register 8 
Bit implementiert und konnte lesen/schreiben mit 8 Bit.

Nun werde ich einfach die gleiche Vorgehenweise für Opencore UART 8 Bits 
und damit sollte es gehen....

[Keller T. (fabito)]

Bei Interesse so sieht meine 8 Bit GPIO Module zur Kommunikation mit 
Lattice PCIe Wishbone Interface aus....

[Keller T. (fabito)]

Hallo zusammen,

Wie kann ich ein Trigger mit Reveal Analyser einstellen so dass ich ab 
rx_st Signal 20 Samples clock nacher warte.
Amders formuliert das Ziel ist es ein gesamte Wishbone Zyklus anschauen 
zu können bis ack_o Signal von GPIO Slave auf 1 wird ?
Ich habe einiges erfolglos probiert....

[Lattice User (Gast)]

Ist jetzt schon eine Weile her, dass ich mich damit beschäftigt habe. 
Momentan schaffe ich es, meine Bugs mit Simulation ond Nachdenken 
auszumerzen.

Du schreibts nicht, was genau du schon probiert hast.
Also erst mal ins blaue.

Du musst im Reavel Inserter erst mal Triggerunits anlegen, ist etwas 
komplex da man auch Sequenzen definieren kann. Im Analyzer kann man dann 
einzelne Triggerunits auswählen.

Am besten Screenshots(*) bei weiteren Fragen.

(*) Im PNG Format!, sonst gibtes Haue von allen möglichen Leuten denen 
langweilig ist.

[Keller T. (fabito)]

Ich gebe dir voll Recht. Also beigefügt entsprechende Reveal 
Inserter/Analyser und Linux Befehle:

Schritt 1: Unter Linux habe ich Memory Write Paket gesendet mit folgende 
Befehle:

q,x - exit
(1)- r|w <addr> [data]: w 0004 FF                      // 0004 
isGPIO:LEDs
(2)- r|w <addr> [data]: w 0004 AA
(3)- r|w <addr> [data]: w 0004 CC

ERKLÄRUNG: Write an ADRESSE xxxx DATEN xx (hexadecimal)

Mein Trigger wird immer ausgelöst wenn es ein TLP (MWr)also start of 
paket =1

Waveform_Memory_Write_0xAA.PNG für (2)
Waveform_Memory_Write_0xCC.PNG für (3)

Nun meine Fragen:

Frage 1: Warum gpio/wb_adr_i also Endpoint nicht die Adresse 0x0004 
bekommt ?

Frage 2: Warum erhalt man immer die Daten an naschte Waveform (Beispiel: 
AA sieht man nur nach Linux Operation 3) FIFO oder?
Habe ich versucht über Reset leer zu machen um entprenche Daten für jede 
Operation zu empfangen aber nichts gebracht.

Frage 3: Wie is Reveal Inserter einzustellen um nnach dem gesendeten TLP 
Paket(MWr) die gesamte Wishbone Zyklus von gpio/wb_cyc_i bis 
gpio/wb_ack_o
anzuschauen?

[Lattice User (Gast)]

Ngii Rayan schrieb:
> Nun meine Fragen:
>
> Frage 1: Warum gpio/wb_adr_i also Endpoint nicht die Adresse 0x0004
> bekommt ?

Siehe PCI/PCIe Spec. Jedes Device bekommt vom BIOS mindestens eine 
Adresse zugewiesen.

>
> Frage 2: Warum erhalt man immer die Daten an naschte Waveform (Beispiel:
> AA sieht man nur nach Linux Operation 3) FIFO oder?
> Habe ich versucht über Reset leer zu machen um entprenche Daten für jede
> Operation zu empfangen aber nichts gebracht.

Du hast als MaxSequence 2 angegeben, beim Analyzer vielleicht 
eingestellt dass er 2 Triggerevents braucht?

>
> Frage 3: Wie is Reveal Inserter einzustellen um nnach dem gesendeten TLP
> Paket(MWr) die gesamte Wishbone Zyklus von gpio/wb_cyc_i bis
> gpio/wb_ack_o
> anzuschauen?

Grössere Buffertiefe, oder einfach mehr als nur 16 im Analyzer 
anschauen.
Buffertiefe 512 statt 256 geht ohne dass mehr EBRs gebraucht werden.
(Ob es reicht weiss ich nicht)

rx_st als einzige Triggerbedingung ist u.U. etwas knapp, bei einem Intel 
basierendem Motherboard kann es sein, dass du mit Vendorspecific 
Messages zugemüllt wirst.

Vielleicht besser auf wb_cyc triggern.

[Keller T. (fabito)]

Hallo zusammen,

Es ist mir gelungen ein 8 Bit Module über Lattice Wishbone Interface 
wb_intf.v anzuschliessen mit Lesen/Schreiben Möglichkeit.

[vhdl]
module wbs_gpio(wb_clk_i, wb_rst_i,
          wb_dat_i, wb_adr_i, wb_cti_i, wb_cyc_i, wb_lock_i, wb_sel_i, 
wb_stb_i, wb_we_i,
          wb_dat_o, wb_ack_o, wb_err_o, wb_rty_o,
          switch_in, led_out
);

input         wb_clk_i;
input         wb_rst_i;

input  [7:0] wb_dat_i;
input  [8:0] wb_adr_i;
input  [2:0] wb_cti_i;
input         wb_cyc_i;
input         wb_lock_i;
input   [1:0] wb_sel_i;
input         wb_stb_i;
input         wb_we_i;
output [7:0] wb_dat_o;
output        wb_ack_o;
output        wb_err_o;
output        wb_rty_o;

input [7:0] switch_in;
output [13:0] led_out; //output [7:0] led_out;


//reg [31:0] scratch_pad;

reg [13:0] led_out;
reg [7:0] wb_dat_local;

//reg [15:0] temp_data;
reg wb_ack_o;

reg wr_delayed; //For VERSA



assign rd = ~wb_we_i && wb_cyc_i && wb_stb_i;
assign wr = wb_we_i && wb_cyc_i && wb_stb_i;

assign wr_use = (!wr_delayed) && wr; //for VERSA

// Need to pipeline the write side to allow the read side time to read 
data
always @(posedge wb_rst_i or posedge wb_clk_i)
begin
  if (wb_rst_i)
  begin
    //scratch_pad <= 32'd0;
    led_out <= 14'd0;
    wb_dat_local <= 32'd0;

    //temp_data <= 0;

    wr_delayed <= 0;//for VERSA
  end
  else
  begin
    wr_delayed<=wr;

  if (wb_cyc_i)
  begin

    case (wb_adr_i)

      9'h000: begin
         if (rd) wb_dat_local <= 8'h30;
      end
      9'h002: begin
         if (rd) wb_dat_local <= 8'h12;
      end

    9'h003: begin
       if (rd) wb_dat_local <= {led_out[13:8],2'b11};
       else if (wr) begin
        led_out[13:8] <= wb_sel_i[0] ? wb_dat_i[5:0] : led_out[13:8];
        //led_out[7:0]  <= wb_sel_i[1] ? wb_dat_i[7:0]  : led_out[7:0];
       end
    end

`ifdef VERSA

    9'h004: begin

     if (rd) wb_dat_local <= 
{led_out[5:4],led_out[3],led_out[3],led_out[2:1],led_out[0],led_out[0]};

    else if (wr_use) begin

          if (led_out[0]&led_out[3]) begin

      led_out[7:0] <= wb_sel_i[1] ? wb_dat_i[7:0] : led_out[7:0];
       end

    else if  (led_out[0]&(!led_out[3])) begin

             led_out[7:0] <= wb_sel_i[1] ? wb_dat_i[7:0] : led_out[7:0];
       end

    else if ((!led_out[0])&led_out[3]) begin
      led_out[7:0] <= wb_sel_i[1] ? wb_dat_i[7:0] : led_out[7:0];
      end

          else if ((!led_out[0])&(!led_out[3])) begin
         led_out[7:0] <= wb_sel_i[1] ? wb_dat_i[7:0] : led_out[7:0];
       end
         end
    end // case: 9'h004


`else


  9'h004: begin
         if (rd) wb_dat_local <= led_out;
         else if (wr) begin
            //led_out[15:8] <= wb_sel_i[0] ? wb_dat_i[15:8] : 
led_out[15:8];
            led_out[7:0]  <= wb_sel_i[1] ? wb_dat_i[7:0]  : 
led_out[7:0];
         end
     end

 `endif

  9'h006: begin
        if (rd) wb_dat_local <= {switch_in};


    end

    endcase

  end // cyc

  end //clk
end

assign wb_dat_o = wb_dat_local;

assign wb_err_o = 1'b0;
assign wb_rty_o = 1'b0;

always @(posedge wb_rst_i or posedge wb_clk_i)
   if (wb_rst_i) begin
      wb_ack_o   <= 0;
   end
   else begin
      wb_ack_o   <= wb_cyc_i & wb_stb_i & (~ wb_ack_o);
   end
endmodule
/vhdl]

Aus diese Vorgehenweeise möchte ich auch Opencore UART 8 Bit Zugriff 
über
Lattice Wishbone Interface wb_intf.v ermöglicen.

ABER diese hat nicht die gleiche Architekture um direkt Zugriff auf 
Register um mein Adressdekoder wie mit GPIO Module zu schreiben.

Hat vielleicht jemand eine Idee wie ich vorgehen sollte ?

[Keller T. (fabito)]

Ich habe eine Idee!

ich glaube es wird über das Module uart_wb.v also uart interface.
Sobald ich damit fertig bin dann melde ich mich
Aber ich würde mich auf weitere Idee freuen.

[Keller T. (fabito)]

Hallo Leute,

Kann man mir vielleicht erklären warum unter the Lattice Wishbone 
Interface Module wb_intf.v wird das Signal wb_sel_o immer wieder gleich 
Werte also auf 1 gesetzt.

Ich habe unterschedliche TLP Datenlänge probiert(length = 1 DW, 
2DW,3DW,4DW) und immer wieder gleich Werte also wb_sel_o <= 2'b11;

Gibt es Fälle wo first_be[3:0] andere Werte aufnehmen als 1111?

Ich würde mich auf Klarheit hier freuen...

     DAT: // start length counter
     begin      
       wb_cyc_o <= 1'b1;
       wb_stb_o <= 1'b1;              
       din_ren_inner <= 1'b0;
       if (wb_ack_i) begin
          wb_adr_o <= wb_adr_o + 2;
          wb_dat_o <= {din[7:0], din[15:8]};
          
          if (word_cnt == {length, 1'b0}) begin 
             sm <= CLEAR;
             wb_cyc_o <= 1'b0;
             wb_stb_o <= 1'b0;
          end
          else begin
             word_cnt <= word_cnt + 1;
          end
          
          if (word_cnt == 1) //second
             wb_sel_o <= {first_be[2], first_be[3]};//first_be[3:2];
          else if (word_cnt == {length_minus1, 1'b0})        //length_minus1 = length - 1 = 2 -1 = 1
             wb_sel_o <= {last_be[0], last_be[1]};//last_be[1:0];
          else if (word_cnt == {length_minus1, 1'b1})              
             wb_sel_o <= {last_be[2], last_be[3]};//last_be[3:2];
          else
             wb_sel_o <= 2'b11;

[Lattice User (Gast)]

Ngii Rayan schrieb:
> Gibt es Fälle wo first_be[3:0] andere Werte aufnehmen als 1111?

Ja natürlich,
Schau dir meine PCIe Traces von oben mal genau an.

Für die meisten hier wären deine Fragen leichter nachzuvollziehen, wenn 
du auch Screenshots von einer Simulation, bzw von Reveal anhängen 
würdest. So muss man immer erst den Quellcode studieren (obendrein 
Verilog, die überwiegende Mehrheit hier nutzt VHDL). Ausserdem aus einem 
einzelenen Schnipsel den gesamten Zusammenhang zu erkennen ist oft nicht 
möglich.

[Keller T. (fabito)]

OK

Ich habe dein Beispiel nochmals angeschaut und die erste Zeile 
beinhaltet folgende:

Length =001 Last BE = 0 First BE = 8

Was dies Datenmäßig bedeutet ? also wieviel Datenmenge werden da 
übertragen ?
1 Byte oder ?

beigefügt meine PCIe Traces (gesendet habe ich nur 1 Byte = 0xFF)also 
sollte ich First BE = 1 oder ?  aber bekomme ich First BE=0xF

Mein Hauptziel ist erkennen zu können aus einem TLP Paket welche 
Datenmenge für Read/Write gebraucht wird (Endpoint)?

[Lattice User (Gast)]

Ngii Rayan schrieb:
> beigefügt meine PCIe Traces (gesendet habe ich nur 1 Byte = 0xFF)also
>
Nein, hast du nicht.
Deine Software/Treiber auf dem PC macht immer 32 bit Zugriffe. Wenn du 
Byte Zugriffe sehen möchtest muss man Treiber buw SW entsrechend 
abändern.

Versuch mal eine ungerade Addresse einzugeben, vielleicht lässt die 
SW/Treiber das ja zu.

[Lattice User (Gast)]

ich habe nochmal nachgeschaut, bei der Windowsvesrion der Lattice SW 
schreibts du einzele Bytes mit

wb 0004 AA

Dürfte bei der Linuxversion das gleiche sein.

Aber eine Einschränkung: Ich verwende diese Software nicht, kann mich 
also irren.

Noch eine Ergänzung

Ngii Rayan schrieb:
> Length =001 Last BE = 0 First BE = 8
>
> Was dies Datenmäßig bedeutet ? also wieviel Datenmenge werden da
> übertragen ?
> 1 Byte oder ?

Übertragen werden 4 Bytes, sieht man auch im Trace, aber nur 1 Byte ist 
gültig.

[Keller T. (fabito)]

Hallo,

Nun habe ich herausgefunden warum ich immer wieder nicht die gesendete 
Daten bisher gesehen habe (oder First BE Signal nicht genau wie erwartet 
passt)

Schauen Sie einfach auf mein TRACE . Da ist festzustellen dass ich mit 
Vendorspecific  Messages zugemüllt werde. Mein TLP Paket kommt erst an 
der dritte Stelle.

gesendet wurde: 1 Byte 0xAA
Jetzt simmt es mit First BE = 1 überein.

Nun eine Frage : Wie kann ich Zugriff für ungerade Adresse steuern.
Mein erste Gedanken ist bei UART beispielsweise jede Adresse zu 
vershieben also Mal 2.

Aber unbenutzte Speichebereiche (bei UART 0 bis 6 Offset wird 0 bis 12)
Hinweis: Endpoint mit 8/16 Slaves Devices alle über Wb_intf.v Module.

Auf Hinweise würde ich mich freuen...

[Lattice User (Gast)]

Ngii Rayan schrieb:
> Schauen Sie einfach auf mein TRACE . Da ist festzustellen dass ich mit
> Vendorspecific  Messages zugemüllt werde. Mein TLP Paket kommt erst an
> der dritte Stelle.

Auf dieses Problem habe ich schon hier hingewiesen:

Beitrag "Re: Lattice Diamond: UART Receiver Siganl Wegoptimiert"

(Letzer Abschnitt)

Ngii Rayan schrieb:
> Nun eine Frage : Wie kann ich Zugriff für ungerade Adresse steuern.
> Mein erste Gedanken ist bei UART beispielsweise jede Adresse zu
> vershieben also Mal 2.

Das ist das einfachste.
Aber auf die Enable achten, bei deinem Slave kommen immer 2 Zugriffe an.
Der 2. mit wb_sel = 00!

(Wobei ich mal 4 nehmen würde)

[Lattice User (Gast)]

Ngii Rayan schrieb:
> Schauen Sie einfach auf mein TRACE . Da ist festzustellen dass ich mit
> Vendorspecific  Messages zugemüllt werde. Mein TLP Paket kommt erst an
> der dritte Stelle.

Habe es noch einmal angeschaut:

In dem Trace ist KEINE Vendorspecific  Message.
(Die würden mit 03xx oder 07xx anfangen)

1. TLP, Schreiben auf Addresse 8 und BE = 3,
2. TLP. Lesen von Addresse 4 und BE = 1
3. TLP, Schreiben auf Addresse 4 und BE = 1

Du hast ganz nebenbei auch noch ein Softwareproblem.

[Keller T. (fabito)]

Mal 2 habe ich vor weil ein 8 Bit UART/CAN nur bitemäßig vom Host 
gelesen wird.

Bei wordweise dann hätte ich sofort an Mal 4 gedacht. Aber bitte dies 
nur Gedanken die geprüft werden sollte.Nicht als Contra (x4) ansehen 
sondern Überlegung.

Ich simuliere erstmals dann melde ich mich mit dem Ergebnis....

[Keller T. (fabito)]

OK ich schaue mir noch meine Software !

[Keller T. (fabito)]

Zum Testzweck habe ich vor 1 Monat ein Paar Read/Write Befehle in meinem 
Treiber eingefügt.(und vergessen!)


Also jetzt endlich ein perfekter TLP Pakete:

Gesendet wurde: 0xAA an Adresse 0x0004

Aus folgende Zeile wurde die wishbone Adresse im Wishbone Interface 
Module berechnet.

       else begin //3DW header
          if (word_cnt == 4) begin
             wb_adr_o[31:16] <= {14'd0, din[1:0]};
             din_ren_inner <= write;
          end
             
          if (word_cnt == 5) begin
             wb_adr_o[15:0]  <= din;
             tran_addr <= din[6:2];

Also wb_adr_o = 0008

[Lattice User (Gast)]

Ngii Rayan schrieb:
> Also wb_adr_o = 0008

Der Wishbonecyclus ist im Trace nicht sichtbar, das was da auf wb_adr 
sichtbar ist stammt von einem vorherigen Zugriff, und hat mit deinem Mal 
2 nichts zu tun.

Du musst auf wb_cyc triggern, oder weit mehr Samples im Reveal anzeigen.

[Keller T. (fabito)]

OK habe ich folgende gemacht

Damit ich TLP Pakete und Wishbone Cycle anschauen kann, habe ich 
folgende Trigger genutzt: rx_st oder ebr_cyc .

Dadurch lassen sich Abläufe von MWr TLP bis Wishbone Zyklus(ebr) 
darstellen.

Gesendet wurde: 0xEE an Adresse 0x2004

passt jetzt oder ?

[Keller T. (fabito)]

Hier mein TRACE für 8 Bit Slave Zugriff (hier : led_out[7:0])

Ich glaube es gut aussieht mit gpio/wb_sel_i= 0 beim zweiten Zugriff 
oder verpasse was da ?

Auf Anmerkungen würde ich mich freuen...

Gesendet wurde: 0xFF an Adresse 0x0000 (8 Bit led)

[Lattice User (Gast)]

Ngii Rayan schrieb:
> Ich glaube es gut aussieht mit gpio/wb_sel_i= 0 beim zweiten Zugriff
> oder verpasse was da ?

Genau darum geht es.
Damit kommen die typischen 8bit WB slaves nicht zurande.

[Keller T. (fabito)]

Hallo zusammen


Nachdem ich erfolgsreich 8 Bit GPIO Slave Module implementiert habe,
habe ich das Ziel Opencore Uart 32 Bit hinten Lattice Wishbone interface 
anzuhängen (wb_intf.v)

Auf diesem Grund habe ich alle UART Adresse verschoben um 4 wie 
folgende:

//`define DATA_BUS_WIDTH_8

`ifdef DATA_BUS_WIDTH_8
 `define UART_ADDR_WIDTH 3
 `define UART_DATA_WIDTH 8
`else
 `define UART_ADDR_WIDTH 5
 `define UART_DATA_WIDTH 32
`endif

// Uncomment this if you want your UART to have
// 16xBaudrate output port.
// If defined, the enable signal will be used to drive baudrate_o signal
// It's frequency is 16xbaudrate

// `define UART_HAS_BAUDRATE_OUTPUT

// Register addresses
/*
`define UART_REG_RB  `UART_ADDR_WIDTH'd0  // receiver buffer
`define UART_REG_TR  `UART_ADDR_WIDTH'd0  // transmitter
`define UART_REG_IE  `UART_ADDR_WIDTH'd1  // Interrupt enable
`define UART_REG_II  `UART_ADDR_WIDTH'd2  // Interrupt identification
`define UART_REG_FC  `UART_ADDR_WIDTH'd2  // FIFO control
`define UART_REG_LC  `UART_ADDR_WIDTH'd3  // Line Control
`define UART_REG_MC  `UART_ADDR_WIDTH'd4  // Modem control
`define UART_REG_LS  `UART_ADDR_WIDTH'd5  // Line status
`define UART_REG_MS  `UART_ADDR_WIDTH'd6  // Modem status
`define UART_REG_SR  `UART_ADDR_WIDTH'd7  // Scratch register
`define UART_REG_DL1  `UART_ADDR_WIDTH'd0  // Divisor latch bytes (1-2)
`define UART_REG_DL2  `UART_ADDR_WIDTH'd1

*/

`define UART_REG_RB  `UART_ADDR_WIDTH'd0  // receiver buffer
`define UART_REG_TR  `UART_ADDR_WIDTH'd0  // transmitter
`define UART_REG_IE  `UART_ADDR_WIDTH'd4  // Interrupt enable
`define UART_REG_II  `UART_ADDR_WIDTH'd8  // Interrupt identification
`define UART_REG_FC  `UART_ADDR_WIDTH'd8  // FIFO control
`define UART_REG_LC  `UART_ADDR_WIDTH'd12  // Line Control
`define UART_REG_MC  `UART_ADDR_WIDTH'd16  // Modem control
`define UART_REG_LS  `UART_ADDR_WIDTH'd20  // Line status
`define UART_REG_MS  `UART_ADDR_WIDTH'd24  // Modem status
`define UART_REG_SR  `UART_ADDR_WIDTH'd28  // Scratch register
`define UART_REG_DL1  `UART_ADDR_WIDTH'd0  // Divisor latch bytes (1-2)
`define UART_REG_DL2  `UART_ADDR_WIDTH'd4

Aber Schauen Sie bitte mein Track ! Das Output entpricht nicht was 
erwartet wird.

Uart Base Adresse: 0x1000

vier Transaktionen habe ich gamacht:
1) Write Daten 0x03 Adresse: 0x1004 (MWr_32Bit_uart_0x03_0x1004.PNG)
2) Read Adresse: 0x1004 (MRd_32Bit_uart_0x1004.PNG )
3) Write Daten 0x83 Adresse: 0x100C(MWr_32Bit_uart_0x83_0x100C.PNG)
4) Read Adresse: 0x100C (MRd_32Bit_uart_0x100C.PNG )

beigefügt mein UART Interface (uart_wb.v)

Ich würde mich auf Hinweise freuen !

[Lattice User (Gast)]

Ngii Rayan schrieb:
> Aber Schauen Sie bitte mein Track ! Das Output entpricht nicht was
> erwartet wird.
>

Doch,
z.B. Addresse 0x1004  kommt als Addresse 0x0004 bei der UART an.

Aber:

//`define DATA_BUS_WIDTH_8

heisst die UART ist als 32 bit Slave konfiguriert. Und wenn ich richtig 
verstanden habe, enthählt sie einen Layer der dann 32bit Zugriffe nach
8 bit übersetzt. Und damit geht alles daneben!
So ein Layer ist keineswegs WB Standard, und schränkt IMO die 
Verwendbarkeit des Cores ein.

Im 8bit Mode wird aber wb_sel nicht ausgwertet, und das wiederum macht 
hier Probleme, da Zugriffe mit wb_sel = 0 erfolgen.

[Keller T. (fabito)]

Hast du völlig Recht !

genauso sieht folgende Trace im 8 Bit Mode aus (Sieh Anhang)
2 Transaktionen habe ich gamacht:

1) Write Daten 0x03 Adresse: 0x1004 (MWr_8Bit_uart_0x03_0x1004.PNG)
2) Read Adresse: 0x1004 (MRd_8Bit_uart_0x1004.PNG )

Dann würde ich gern das UART Interface Module(uart_wb.v sih voheriges 
Anhang) so ändern mit select Signal für 8 Bit Mode:

`ifdef DATA_BUS_WIDTH_8 // 8-bit data bus
always @(posedge clk or posedge wb_rst_i)
  if (wb_rst_i)
    wb_dat_o <= #1 0;
  else
    wb_dat_o <= #1 wb_dat8_o;

always @(wb_dat_is)
  //wb_dat8_i = wb_dat_is;

---- >        wb_dat8_i <= wb_sel_i[1] ? wb_dat_is : wb_dat8_i;    < ---

`else // 32-bit bus
// put output to the correct byte in 32 bits using select line


Und Mal schauen oder bringt diese allein NICHT!

[Lattice User (Gast)]

Ngii Rayan schrieb:
> Dann würde ich gern das UART Interface Module(uart_wb.v sih voheriges
> Anhang) so ändern mit select Signal für 8 Bit Mode:

Ja genau.
Ob die Änderungen ausreichen wird man sehen.

[Keller T. (fabito)]

Hier meine Simulation mit wb_sel_i für UART Slave Device.

Nur habe ich immer wb_dat8_i = xx

Hat jemand vielleicht eine Idee was mir noch fehlt ?

always @(wb_dat_is)

        //Hier meine Änderung
       //wb_dat8_i = wb_dat_is;
   wb_dat8_i = wb_sel_i[1] ? wb_dat_is : wb_dat8_i;

gesendet wurde: 0xDCBA an Adresse :0x0002

[Lattice User (Gast)]

Der gezeigte Ausschnitt (Es ist ein kombinatorischer Prozess) hat gleich 
2 Probleme.

1. Die Sensitivitylist ist unvollständig.
2. Es ist ein Latch beschrieben, sollte man bei einem FPGA vermeiden.

Zu 1: In Verilog 2001 (default bei Lattice) kann man faul sein und 
einfach @(*) schreiben. (Nur für kombinatorische Prozesse)

Im Trace fehlt wb_dat_is.

Übrigens auch ein kleines Lob.
Du hast erkannt, dass man bei komplexen Designs auch Ausschnitte 
simulieren kann, im Gegensatz zu manchen mit angeblichen 10 Jahren 
Aerospace erfahrung, die meinen weil das Gesamtdesign zu komplex ist man 
auf die Simulation verzichten muss.

[Keller T. (fabito)]

Hallo,

Danke für das Lob! Durch die Simulation versteht man einfach besser was 
drin lauft! Also würde ich empfehlen...

jetzt sieht meine Simulation gut aus!

Gesendet wurde
0x08 an Adresse 0x04 (also ier = Interrupt Enable Register)
Sieh Simulation_MWr_0x08_IER.PNG

und

0x83 an Adresse 0x0C (also lcr = Line Control Register)
Sieh Simulation_MWr_0x83_LCR.PNG

Die Inhalte dieser Registern sind ganz unten zu sehen (Simulation)

Nochmals zur Errinerung wurde die Offset Register wegen Wishbone 
Interface Module um 4 verschoben.

Also ier = offset:1 nun 4
     lcr = offset:3 nun C

Auf Hinweise würde ich mich freuen ...

[Keller T. (fabito)]

Hier eine Verbesserung !

Bei
0x83 an Adresse 0x0C (also lcr = Line Control Register)

Stimmen die Adresse nicht anstatt 0x04 sollte man eher 0x0C

Nun korrigiert

Sieh Simulation_MWr_0x83_LCR.PNG

[Keller T. (fabito)]

Simulation verbessert mit first_be = 1 Byte (Signal hinzugefügt)

gesendet 1 Byte = 0x83 an Adresse 0x0C (also lcr = Line Control 
Register)

Sieh Simulation_MWr_0x83_LCR.PNG

[Keller T. (fabito)]

Auf der vorherige Simulation wurde auch die sel Signals besser behandelt 
(0 sobald die Daten geschrieben wurden)

[Keller T. (fabito)]

Hallo zusammen,

Ich habe erfolgreich mein OpencoreCAN Controller über Wishbone interface 
(wsb.v)simuliert.

Siehe Anhang...

alle Adresse wurden Mal 4 also :
     Control Register = 0x00
     Command Register = 0x04
     Status Register = 0x08
     Interrupt Register = 0x0C
     Acceptance Code Register = 0x10
     .....

Nur habe ich Probleme nach dem *.bit Download auf dem Board.
Nach dem Schreiben kann ich nicht das Gleiche Lesen...

Hat es vielleicht mit Timing zu tun da ich 125 MHz für wb_clk_i und 
clk_i benutzt habe? Siehe unten

 can_top   can ( 
    .wb_clk_i      (clk_125),
    .wb_rst_i        (~core_rst_n),
      .wb_adr_i      (can_adr_i),
      .wb_dat_i       (can_dat_i),
      //.wb_sel_i       (can_sel_i),   
      .wb_we_i        (can_we),
      .wb_stb_i       (can_stb),
      .wb_cyc_i       (can_cyc),
      .wb_ack_o       (can_ack),
      .wb_dat_o       (can_dat_o),   
    
    //CAN signals
    .tx_o(can_stx_o), 
      .rx_i(can_srx_i),  
    
      //ack clock
    .clk_i(clk_125),

      //interrupt
          .irq_on(),
      .clkout_o()
    
    );

[Lattice User (Gast)]

Ngii Rayan schrieb:
> Hat es vielleicht mit Timing zu tun da ich 125 MHz für wb_clk_i und
> clk_i benutzt habe? Siehe unten

Geht es denn in der Simulation?

Wenn die Constraints stimmen, und die Timinganalyse keine Fehler findet, 
sollte es von dieser Seite in Ordnung sein.

[Keller T. (fabito)]

Hallo,

Es hat mit dem CAN Bus geklappt es war einen kleinen Fehler von mir. 
Also der Adresse Bus war in der Luft .

Mit 125 MHz für wishbone und CAN_clock hat problemlos funktioniert.
Also gleicher Takt für PCIe - CAN

Nun meine Frage:

PCI Express ist mit125 MHZ getaktet.
Welche Vorteil oder Risiken gibt es wenn ich Enpoint Devices mit andere 
Clock takte.
Beispiel
1)- 50 MHz On Board für Asynchrone SRAM zum Waitstate Generierung.
2)- 25 MHz PLL für CAN wishbone(wb_clk_i) + CAN Clock(clk_i).


Gibt es zpezielle Anforderungen für Transport von Daten zwischen 
unterschiedliche
Taktdomänen (125MHZ-PCIe und 50MHZ-CAN) oder (125MHZ-PCIe und 25 
MHZ-CAN)?

Was wäre die sichere Lösungsansatzt ?

[Lattice User (Gast)]

Was spricht dagegen den CAN Controller mit 125 MHz zu betreiben?

Zu klären ist allerdings folgendes:
Die 125 MHz des PCI Express Designs leiten sich von der Rerefenzclock 
des PC's ab. Und diese ist mit SCC (Spread Spectrum Clocking) verseucht. 
Kann man bei manchen MBs abschalten. Ansonsten wie sind die 
Anforderungen von CAN an die Clockgenauigkeit und Stabilität?

Ngii Rayan schrieb:
> Gibt es zpezielle Anforderungen für Transport von Daten zwischen
> unterschiedliche
> Taktdomänen (125MHZ-PCIe und 50MHZ-CAN) oder (125MHZ-PCIe und 25
> MHZ-CAN)?

Ja, die gibt es. Lothar schreibt dass es nichts für den Anfänger ist, 
wenn man da etwas falsch macht gibt es sporadische scheinbar 
unerklärliche Fehler und in der Folge viele graue oder ausgerissene 
Haare.

[Keller T. (fabito)]

Anforderungen von CAN:
Bis jetzt wurde 25MHz Ozillator für 12.5 MHz(CAN Controller) und 500 
kbps genutzt. Die Kompatibilität sollte gewährleistet werden .

Soll ich da Waitstates implementieren ?
Wenn Ja wie kann ich es am einfachstens mit Lattice implementieren?

[Lattice User (Gast)]

Ngii Rayan schrieb:
> Soll ich da Waitstates implementieren ?

Das reicht nicht.


Wishbone ist ein synchroner Bus, d.h. man muss alle Teilnehmer (Master 
und Slaves) mit der gleichen Clock versorgen.
Es ist sicher möglich eine WB -> WB Bridge zu implementieren um 
Clockdomaingrenzen zu überwinden, das ist aber nicht ganz trivial.

Übrigens hat das mit dem ursprünglichen Thema nichts mehr zu tun, es 
wäre vielleicht sinnvoll einen neuen Thread speziell zum Wishbone Thema 
aufzumachen, um wieder ein breiteres Publikum anzusprechen.

[Martin M. (capiman)]

Wäre es möglich, einen Stand deiner Implementierung zu bekommen
(z.B. dein Beispiel mit einem UART würde schon reichen),
so dass man dies als Grundlage für eigene Versuche benutzen kann?
Oder sind deine Entwicklungen closed source
und damit leider nicht verfügbar?

[Keller T. (fabito)]

Das wäre eine Lösung !
Von Lattice umsetzbar über IP Express Tool


FIFO_DC

A dual-clock FIFO using EBR (Embedded Block RAM). The FIFO_DC module 
provides a variety of FIFO memory organizations. This FIFO has two 
clocks. The generated netlist has gray counters to handle clock domain 
transfer. Ports, properties, and functionality are described in detail 
in the “See Also” section below.

Ich werde es umsetzen!

[Keller T. (fabito)]

Hallo !

Es hat problemlos funktioniert.
Grund dafür ist : PCIe 125 MHz zur gleiche clock domäne mit mein 25 MHz 
PLL can_clk.

can_top   can ( 
    .wb_clk_i      (clk_125),
    .wb_rst_i        (~core_rst_n),
      .wb_adr_i      (can_adr),
      .wb_dat_i       (can_dat_i),
      //.wb_sel_i       (can_sel_i),   
      .wb_we_i        (can_we),
      .wb_stb_i       (can_stb),
      .wb_cyc_i       (can_cyc),
      .wb_ack_o       (can_ack),
      .wb_dat_o       (can_dat_o),   
    
    //CAN signals
    .tx_o(can_stx_o), 
      .rx_i(can_srx_i),  
    
      //ack clock
    .clk_i(can_clk), // .clk_i(clk_125),

      //interrupt
          .irq_on(),
      .clkout_o()
    
    );

[Keller T. (fabito)]

Zur Martin Maurer (capiman) Nachfrage!

Ich kann leider nur wegen Datenschtutz
dir nur Hinweise über deine Probleme geben.
Mehr darf ich leider nicht.
Überdies lernst du auch viel by learning by doing.

[Lattice User (Gast)]

Ngii Rayan schrieb:
> Es hat problemlos funktioniert.
> Grund dafür ist : PCIe 125 MHz zur gleiche clock domäne mit mein 25 MHz
> PLL can_clk.

Nein, das ist nicht der Grund.

Der Grund ist, dass die Entwickler des Opencore CANs es vorgesehen haben 
(aber nirgends dokumentiert, daher taugt der Core nicht wirklich für 
Anfänger).

Hier ein kleiner Auszug (für den Rückweg):

  always @ (posedge wb_clk_i)
  begin
    cs_ack1 <=#Tp cs_sync3;
    cs_ack2 <=#Tp cs_ack1;
    cs_ack3 <=#Tp cs_ack2;
  end
 
  // Generating acknowledge signal
  always @ (posedge wb_clk_i)
  begin
    wb_ack_o <=#Tp (cs_ack2 & (~cs_ack3));
  end

Da ist noch viel mehr.
Wenn du verstanden hast um was es hier geht wirst du sehen dass es auch 
mit einer asynchronen CAN Clock gehen sollte.

[Keller T. (fabito)]

Danke für den Hinweis!

Ich komme wieder zu dir nachdem ich es analysiert und verstanden habe.

[Lattice User (Gast)]

Ngii Rayan schrieb:
> Zur Martin Maurer (capiman) Nachfrage!
>
> Ich kann leider nur wegen Datenschtutz
> dir nur Hinweise über deine Probleme geben.
> Mehr darf ich leider nicht.
> Überdies lernst du auch viel by learning by doing.

Dir ist klar dass sowohl der CAN Core, als auch der UART Core von 
Opencores unter der LGPL Lizenz stehen?
Spätesten deinen eigenen Kunden wirst du alle deinen Modifikationen 
offenlegen müssen. Obendrein musst du ihnen die Möglichkeit geben selbst 
Änderungen an den LPGL Cores zu machen, was im Prinzip darauf 
hinausläuft, dass du deinen gesamten Source überreichen musst.

Also was soll die Geheimniskrämerei.

[Keller T. (fabito)]

Bin ich einverstanden!

Nur darf ich nicht das gesamte Design senden.(Vielleicht am Ende )
Hinweis was zur Opencore geändert werden soll ok!

Ich möchte auch dass er viel verstehe. Von dir habe ich Hinweis immer 
bekommen dann habe ich versuche by doing herauszufinden.

Wenn du alles zu mir gesendet hättest. Glaub mir hätte ich keine 
Simulation gemacht was meinn Vertandnis verstärkt hat.

Also ich bin bereit zu helfen. Ich schreibe eine Private Mail zu ihm so 
können wir Kontakt halten.

Übrigens in welchem Opencore Can Controller Module ist dein kleiner 
Auszug (für den Rückweg):

  always @ (posedge wb_clk_i)
  begin
    cs_ack1 <=#Tp cs_sync3;
    cs_ack2 <=#Tp cs_ack1;
    cs_ack3 <=#Tp cs_ack2;
  end
 
  // Generating acknowledge signal
  always @ (posedge wb_clk_i)
  begin
    wb_ack_o <=#Tp (cs_ack2 & (~cs_ack3));
  end

Das finde ich nicht hast du vielleicht ein anderer Opencore ?

[Keller T. (fabito)]

Zum Thema Clock Domain Crossing und Lösungsansätze

würde ich folgende Link empfehlen.

http://filebox.ece.vt.edu/~athanas/4514/ledadoc/html/pol_cdc.html

[Keller T. (fabito)]

Ich habe der kleiner Auszug (für den Rückweg gesehen

[Lattice User (Gast)]

Ngii Rayan schrieb:
> Das finde ich nicht hast du vielleicht ein anderer Opencore ?

Ich habe keinen, nur online geschaut. (http://opencores.org/project,can)
Da ich auf Opencores nur einen CAN Controller für WB in Verilog gefunden 
habe, nahm ich an, dass es der ist den du auch benutzt. Ausserdem gibt 
es dort die 2 getrennten Clocks wb_clk_i und clk_i, wie in deinen 
Auszügen.

Die Stelle ist im module can_top, ziemlich weit unten.

[Keller T. (fabito)]

OK

Das habe ich gesehen. Ich mache nicht weiter ohne es verstanden zu 
haben!

[Keller T. (fabito)]

Zu Synchronistaion Wishbone_Clk und Can Clock !

Zum besseren Verstandnis

[Lattice User (Gast)]

Kleiner Hinweis:

Das #Tp im Opencan Core ist überflüssig und wirkt nur auf die 
Simulation, manche brauchen es halt um sich Sand in die Augen zu 
streuen.
Damit hat der kleine Versatz zwischen der roten Linie und den Clocks 
nichts zu sagen. (Wie gesagt nur Sand im Auge des Betrachters)

(An die VHDLer, das ist das Gleiche wie ein after in VHDL)

Um zu sehen was da wirklich passiert, solltes du die Simulation mal mit 
einer asynchronen Clock machen, mit einer möglichst krummen bezogen auf 
die 125 MHz.

[Keller T. (fabito)]

OK!

so sieht es aus: sieh Anhang: besser habe ich verstanden und bin 
gespannt was mit dem UART für 25 MHz passieren wird ?

Nun eine Frage:

Aus meinem bisherigen Verstandnis dachte ich dass, Prefetchable Memory 
BAR immer 64 Bit sein sollte.Kann man auch mit 32 Bit oder ?

Mein Ziel ist Asynchrone SRAM 1 MB als Endpoint Device was Prefetchable 
bedeutet.
Nun darf man 32 Bit (1 BAR) oder muss man 64 Bits(also 2 BARs) ?

[Keller T. (fabito)]

Tut mir Leid Hier die Simulation !


Nun eine Frage:

Aus meinem bisherigen Verstandnis dachte ich dass, Prefetchable Memory
BAR immer 64 Bit sein sollte.Kann man auch mit 32 Bit oder ?

Mein Ziel ist Asynchrone SRAM 1 MB als Endpoint Device was Prefetchable
bedeutet.
Nun darf man 32 Bit (1 BAR) oder muss man 64 Bits(also 2 BARs) ?

[Keller T. (fabito)]

Hat als auch mit dem UART Opencore (25 MHz) zumindest mit der Simulation 
geklappt.

Wishbone Inerface= 125 MHz
UART = 25 MHz

Auch wenn Ack Signal 4 Mal gesendet wird
nur der erster berücksichtigt ist (we_0=1 sonst we_0=0)

[Lattice User (Gast)]

Ngii Rayan schrieb:
> Aus meinem bisherigen Verstandnis dachte ich dass, Prefetchable Memory
> BAR immer 64 Bit sein sollte.Kann man auch mit 32 Bit oder ?
>

Ja sollte gehen.

Bei PCI Express ist das übrigens egal, du kannst sowohl 32 als 64 Bit 
BARS beliebig kennzeichnen.

Die Unterscheidung stammt aus der PCI Bridge Spezification und hat damit 
zu tun dass es beim PCI Protokol keine Burstlänge gibt, sondern der 
Burst beendet ist wenn die CPU keine Lust mehr hat. Damit es schnell 
geht muss eine PCI Bridge also auf der Deviceseite vorrauslesen 
(prefetch) und zuvielgelesene Daten wegschmeissen.

Damit die PCI Bridge unterscheiden kann ob prefetch erlaubt its, hat sie 
zwei Addressfenster, je eines für nonprefetch und prefetch. Das für 
nonprefetch kann nur 32bit Addressen umsetzen.

Eine PCIe Bridge hat wegen der Rückwärtskompatibiltät auch diese 2 
Fenster, braucht aber die Zugriffe nicht unterschiedlich behandeln da 
das PCIe Protokoll eine Längenangabe enthält.

Allerdings dürften die meisten BIOSe und Betriebsysteme immer noch so 
tun als ob es wichtig wäre.
Wenn das BIOS/OS auf eine 64bit Bar ohne prefetch stösst, wird halt 
immer noch eine 32bit Addresse zugewiesen und verschwendet wertvollen 
Addressraum im < 4GByte Bereich. Übrigens für jedes Device gleich 1 
MByte, egal wie klein deine BARs sind.


> Mein Ziel ist Asynchrone SRAM 1 MB als Endpoint Device was Prefetchable
> bedeutet.
> Nun darf man 32 Bit (1 BAR) oder muss man 64 Bits(also 2 BARs) ?

Die ist klar was Prefetchable auch cachable aus der Sicht der CPU 
bedeutet und du extra Aufwand im Treiber hast?

Ngii Rayan schrieb:
> Hat als auch mit dem UART Opencore (25 MHz) zumindest mit der Simulation
> geklappt.
>
> Wishbone Inerface= 125 MHz
> UART = 25 MHz
>

Wofür wird die UART Clock verwendet? Nur für den Baudrategenerator, oder 
auch für den Registerzugriff?
Wenn ersteres, hat das Uartmodule intern korrekte Clockdomaincrossings?

[Keller T. (fabito)]

Hallo zusammen,

eine Woche lang war ich krank !

Erstens vien Dank für die 32/64 Bit BARs Erklärung. Ich werde weiterhin 
mit 64 Bits für SRAM machen.

Nun zu deiner Fragen:

1) Wofür wird die UART Clock verwendet? Nur für den Baudrategenerator, 
oder auch für den Registerzugriff?
2) Wenn ersteres, hat das Uartmodule intern korrekte 
Clockdomaincrossings?

Antworte: auch für den Registerzugriff

Nach dem Test funktioniert es aber ich werde den Test mehrmal 
durchführen um eine Sicherheit zu haben.

Nun meine Fragen:

Es is nirgendwo geschrieben ob Opencore CAN/UART Interrupt Hight oder 
Low aktive sind.

Aber wenn man der Blockdiagram anschaut(Sieh Anhang),
scheint UART16550 aktive High aktive und CAN aktive Low zu sein. Ist es 
So oder bin ich falsch?
Ich benutze MSI (rising Edge Interrupt). Nur wollte ich mir klar machen 
welche Typ von Interrupts von Slave Device generiert werden.

[Keller T. (fabito)]

Hallo alle Lattice user,

Hier ein Beispiel zur Lattice Wishbone Interface <-->8Bit UART Slave 
Kommunikation als Basis für einen Einstieg.
Bei Fragen stehe ich gern zur Verfügung.

[Raya N. (rayan)]

Hallo zusammen,

ich arbeite auch mit Lattice IP Core und habe Problem mit der 
Adressierung:

Ursprunglich wird der Zugrrif auf Devices wie folgende:

wb_arb #(.c_DATA_WIDTH(16),
         .S0_BASE     (32'h0000),
         .S1_BASE     (32'h4000),
         .S2_BASE     (32'h1000),
         .S3_BASE     (32'h5000)
) wb_arb (
    .clk(clk_125),
    .rstn(core_rst_n),
  
    // PCIe Master 
    .m0_dat_i(pcie_dat_o), 
    .m0_dat_o(pcie_dat_i), 
    .m0_adr_i(pcie_adr),
    .m0_sel_i(pcie_sel), 
    .m0_we_i(pcie_we), 
    .m0_cyc_i(pcie_cyc),
    .m0_cti_i(pcie_cti),
    .m0_stb_i(pcie_stb), 
    .m0_ack_o(pcie_ack), 
    .m0_err_o(), 
    .m0_rty_o(), 
    
    // DMA Master
    .m1_dat_i(16'd0), 
    .m1_dat_o(), 
    .m1_adr_i(32'd0),
    .m1_sel_i(2'd0), 
    .m1_we_i( 1'b0), 
    .m1_cyc_i(1'b0),
    .m1_cti_i(3'd0),
    .m1_stb_i(1'b0), 
    .m1_ack_o(), 
    .m1_err_o(), 
    .m1_rty_o(),         

    // GPIO 32-bit
    .s0_dat_i(gpio_dat_o), 
    .s0_dat_o(gpio_dat_i), 
    .s0_adr_o(gpio_adr), 
    .s0_sel_o(gpio_sel), 
    .s0_we_o (gpio_we), 
    .s0_cyc_o(gpio_cyc),
    .s0_cti_o (gpio_cti),
    .s0_stb_o(gpio_stb), 
    .s0_ack_i(gpio_ack), 
    .s0_err_i(gpio_err),
    .s0_rty_i(gpio_rty), 
    
    // DMA Slave
    .s1_dat_i(16'd0), 
    .s1_dat_o(), 
    .s1_adr_o(), 
    .s1_sel_o(), 
    .s1_we_o (), 
    .s1_cyc_o(),
    .s1_cti_o(),
    .s1_stb_o(), 
    .s1_ack_i(1'b0), 
    .s1_rty_i(1'b0),
    .s1_err_i(1'b0),
    
    // EBR
    .s2_dat_i(ebr_dat_o), 
    .s2_dat_o(ebr_dat_i), 
    .s2_adr_o(ebr_adr), 
    .s2_sel_o(ebr_sel), 
    .s2_we_o (ebr_we), 
    .s2_cyc_o(ebr_cyc),
    .s2_cti_o(ebr_cti),
    .s2_stb_o(ebr_stb), 
    .s2_ack_i(ebr_ack), 
    .s2_err_i(ebr_err),
    .s2_rty_i(ebr_rty),
    
    // Not used
    .s3_dat_i(16'd0), 
    .s3_dat_o(), 
    .s3_adr_o(), 
    .s3_sel_o(), 
    .s3_we_o (), 
    .s3_cyc_o(),
    .s3_cti_o(),
    .s3_stb_o(), 
    .s3_ack_i(1'b0),
    .s3_rty_i(1'b0), 
    .s3_err_i(1'b0)
);

Nur möchte ich eher sowas:

wb_arb #(.c_DATA_WIDTH(16),
         .S0_BASE     (32'h4000),
         .S1_BASE     (32'h4008),
         .S2_BASE     (32'h4010),
         .S3_BASE     (32'h4018)
) wb_arb (

erlauben dann habe der Wishbone Arbiter so angepasst:

always @(posedge clk or negedge rstn)
begin
  if (~rstn)
  begin
    s0_sel <= 1'b0;
    s1_sel <= 1'b0;
    s2_sel <= 1'b0;
    s3_sel <= 1'b0;
  s4_sel <= 1'b0;
  s5_sel <= 1'b0;
  s6_sel <= 1'b0;
  s7_sel <= 1'b0;
  s8_sel <= 1'b0;
  s9_sel <= 1'b0;
  end
  else
  begin
    s0_sel <= ~rr[0] ? (m0_adr_i[15:0] >= S0_BASE[15:0]) : 1'b0; // M0 (PCIe) only talks to S0 and S1
    s1_sel <= ~rr[0] ? (m0_adr_i[15:0] >= S1_BASE[15:0]) : 1'b0;
    s2_sel <= (m_adr[15:0] >= S2_BASE[15:0]);
    s3_sel <= (m_adr[15:0] >= S3_BASE[15:0]); 
  s4_sel <= (m_adr[15:0] >= S4_BASE[15:0]); 
  s5_sel <= (m_adr[15:0] >= S5_BASE[15:0]); 
  s6_sel <= (m_adr[15:0] >= S6_BASE[15:0]); 
  s7_sel <= (m_adr[15:0] >= S7_BASE[15:0]); 
  s8_sel <= (m_adr[15:0] >= S8_BASE[15:0]);
  s9_sel <= (m_adr[15:0] >= S9_BASE[15:0]);  
  end
end

Leider kann ich damit nur Devices 4000 und 4010 zugreifen aber nicht
4008 und 4018


Bitte was soll ich noch da machen um mein Ziel zu erreichen ?

Beigefügt ist der Arbiter zu finden..