Hi All: My first posting. I've been mucking around with the UART core http://www.opencores.org/cores/uart16550/ 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 http://www.opencores.org/forums.cgi/cores/attachments/20040122/538b766a/attachment.htm

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 http://www.opencores.org/cores/uart16550/ 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 http://www.opencores.org/forums.cgi/cores/attachments/20040122/301f64e4/attachment.htm

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 http://www.opencores.org/cores/uart16550/ 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 http://www.opencores.org/mailman/listinfo/cores -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums.cgi/cores/attachments/20040122/7d317b16/attachment.htm

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: cores-bounces at opencores.org [mailto:cores-bounces at opencores.org] On Behalf Of bporcella Sent: Thursday, January 22, 2004 7:48 PM To: Discussion list about free open source IP cores Subject: Re: [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 richard at asics.ws> To: 'Discussion list cores at opencores.org> 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 http://www.opencores.org/cores/uart16550/ 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 http://www.opencores.org/mailman/listinfo/cores -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums.cgi/cores/attachments/20040123/64f8551b/attachment.htm