LOGIN   :::   RECOVER PASS   :::   GET ACCOUNT    
Browse
  • Projects
  • Code (CVS)
  • Forums
  • News
  • Articles
  • Polls
  •  
    OpenCores
  • FAQ
  • CVS HowTo
  • Mission
  • Media
  • Tools
  • Advertise
  • Mirrors
  • Logos
  • Contact us
  • Job Opportunity
  •  
    Tools
  • Search
      
  • Download Cores (CVSGet)
  •  
    More
  • Wishbone
  • Perlilog
  • EDA tools
  • OpenTech CD
  •  
    Navigation: All forums > Cores > Message List > Message Post

    Message

    Reply | Reply all
    Date Prev | Date Next | Thread Prev | Thread Next Date Index | Thread Index

    From: Igor Mohor(opencores)<igorm@o...>
    Date: Fri Jan 23 02:35:09 CET 2004
    Subject: [oc] Wishbone Addressing
    Top
    Hi, everybody.


    This core was done some time ago.

    At the beginning uart only had 8-bit interface and that is the reason
    for addressing.
    There was no wb_sel line, too.
    Afterwards something needed to be added to support 32-bit interface.

    And that's it. No magic behind. However this core is not a nice one but
    was well tested in HW so
    nobody has a strong wish to rewrite it.

    Best regards,
    Igor


    -----Original Message-----
    From: attachment.htm

    I have a question about the use of the sel_o[3:0] lines in this design
    relative to the wishbone spec.

    In the 32 bit bus configuration, these select lines are used to
    multiplex
    8 bit registers onto selected positions of the bus. code in question is: // put output to the correct byte in 32 bits using select line always @(posedge clk or posedge wb_rst_i) if (wb_rst_i) wb_dat_o <= #1 0; else if (re_o) case (wb_sel_is) 4'b0001: wb_dat_o <= #1 {24'b0, wb_dat8_o}; 4'b0010: wb_dat_o <= #1 {16'b0, wb_dat8_o, 8'b0}; 4'b0100: wb_dat_o <= #1 {8'b0, wb_dat8_o, 16'b0}; 4'b1000: wb_dat_o <= #1 {wb_dat8_o, 24'b0}; 4'b1111: wb_dat_o <= #1 wb_dat32_o; // debug interface output default: wb_dat_o <= #1 0; endcase // case(wb_sel_i) In my humble opinion, this treatment is neithor logical, nor implied by the wishbone spec. Furtheremore, register addresses seem wrong to me: // 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 in the 32 bit configuration (for which there are properly 5 address bits) -- the MSB's are ignored. The transmit and recieve registers (which presumably cover 4 byte addresses) are "overwritten" by 8 bit control registers. I suppose that a driver could be written under these circumstances -- and I must believe one or more has in fact been written, but is this really the desired behavior??? bj Porcella _____ _______________________________________________ attachment.htm -------------- next part -------------- An HTML attachment was scrubbed... URL: attachment.htm

    ReferenceAuthor
    [oc] Wishbone AddressingBporcella

     
    Copyright (c) 1999 OPENCORES.ORG. All rights reserved.