|
Message
From: bporcella<bporcella@s...>
Date: Thu Jan 22 19:47:54 CET 2004
Subject: [oc] Wishbone Addressing
Richard:I don't think I made my point very clearly. (and in fact i was a little confused -- I thought authors intended to
transfer 32 bit data to/from fifo ---- on inspection clearly not the case, this is a byte oriented core).
However,
In the 32 bit configuration registesr are mapped at addresses:
0 (fifo data)
1 UART_REG_IE
2 UART_REG_II
etc
Where they (probably) should be mapped:
0 (fifo data)
4 UART_REG_IE
8 UART_REG_II
etc
As I think about it, I suppose that one could obtain the operation that I believe is desired by wiring the bus address 2 to core address 0 etc...
as is generally done in PC systems. (eithor hardwire the input selects to 'b0001 - or perhaps better just look at sel[0].
Still hoping to get a comment from original authors -- Its easy to miss stuff.
bj
----- Original Message -----
From: Richard Herveille
To: 'Discussion list about free open source IP cores'
Sent: Wednesday, January 21, 2004 11:24 PM
Subject: RE: [oc] Wishbone Addressing
The SEL lines signal on what byte(s) (if you're using 8bit fragmentation) data is expected (read operation) or on what byte(s) valid data is present (during a write operation).
For a read operation on a 32bit databus you can always output the entire qword; simply ignoring the SEL bits, because the correct data is always present on the correct byte(s). The other bytes are defined to contain invalid data, so it is perfectly legal to output the entire 32bit dataword.
For a write operation you need to mask your internal write signal with the SEL lines of course.
Now as for the code-piece below, I don't know what the authors intend with it. But simply outputting the correct register would have done the trick as well. Nor does it make sense to add an enable (re_o) to the wb_dat_o registers. Always output data, even during a write operation, the external bus arbiter (e.g. CONMAX IP core) takes care of routing the correct data.
Just my 2cents, the original authors should comment on it as they understand what they intend to build.
Richard
Hi All:
My first posting. I've been mucking around with the UART
core 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
|
 |
Browse
