From: Alistair Francis <alistair23@gmail.com>
To: LIU Zhiwei <zhiwei_liu@c-sky.com>
Cc: "open list:RISC-V" <qemu-riscv@nongnu.org>,
Bin Meng <bmeng.cn@gmail.com>,
Alistair Francis <alistair.francis@wdc.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>
Subject: Re: [PATCH v5 07/11] hw/char: Initial commit of Ibex UART
Date: Wed, 3 Jun 2020 08:56:07 -0700 [thread overview]
Message-ID: <CAKmqyKOvv2HCpXoD+8E5q2S7JqSDfT7_z3+_=cKFLi+H92itjw@mail.gmail.com> (raw)
In-Reply-To: <ec0a7545-1793-d1a9-fccf-068496cf1f0a@c-sky.com>
On Wed, Jun 3, 2020 at 3:33 AM LIU Zhiwei <zhiwei_liu@c-sky.com> wrote:
>
> On 2020/6/3 1:54, Alistair Francis wrote:
> > On Tue, Jun 2, 2020 at 5:28 AM LIU Zhiwei<zhiwei_liu@c-sky.com> wrote:
> >> Hi Alistair,
> >>
> >> There are still some questions I don't understand.
> >>
> >> 1. Is the baud rate or fifo a necessary feature to simulate?
> >> As you can see, qemu_chr_fe_write will send the byte as soon as possible.
> >> When you want to transmit a byte through WDATA, you can call
> >> qemu_chr_fe_write directly.
> > So qemu_chr_fe_write() will send the data straight away. This doesn't
> > match what teh hardware does though. So by modelling a FIFO and a
> > delay in sending we can better match the hardware.
> I see many UARTs have similar features. Does the software really care about
> these features? Usually I just want to print something to the terminal
> through UART.
In this case Tock (which is the OS used for OpenTitan) does car about
these features as it relies on interrupts generated by the HW to
complete the serial send task. It also just makes the QEMU model more
accurate.
> Most simulation in QEMU is for running software, not exactly the details
> of hardware.
> For example, we will not simulate the 16x oversamples in this UART.
Agreed. Lots of UARTs don't bother modelling the delay from the
hardware as generally it doesn't matter. In this case it does make a
difference for the software and it makes the QEMU model more accurate,
which is always a good thing.
>
> There is no error here. Personally I think it is necessary to simulate
> the FIFO and baud rate,
> maybe for supporting some backends.
So baud rate doesn't need to be modelled as we aren't actually sending
UART data, just pretending and then printing it.
>
> Can someone give a reasonable answer for this question?
Which question?
> >> 2. The baud rate calculation method is not strictly right.
> >> I think when a byte write to FIFO, char_tx_time * 8 is the correct time
> >> to send the byte instead of
> >> char_tx_time * 4.
> > Do you mind explaining why 8 is correct instead of 4?
> Usually write a byte to WDATA will trigger a uart_write_tx_fifo.
> Translate a bit will take
> char_tx_time. So it will take char_tx_time * 8 to transmit a byte.
I see your point. I just used the 4 as that is what the Cadence one
does. I don't think it matters too much as it's just the delay for a
timer (that isn't used as an accurate timer).
> >> 3. Why add a watch here?
> > This is based on the Cadence UART implementation in QEMU (which does
> > the same thing). This will trigger a callback when we can write more
> > data or when the backend has hung up.
> Many other serials do the same thing, like virtio-console and serial. So
> it may be a common
> interface here. I will try to understand it(Not yet).
Yep, it's just a more complete model of that the HW does.
Alistair
next prev parent reply other threads:[~2020-06-03 16:06 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-28 22:14 [PATCH v5 00/11] RISC-V Add the OpenTitan Machine Alistair Francis
2020-05-28 22:14 ` [PATCH v5 01/11] riscv/boot: Add a missing header include Alistair Francis
2020-05-28 22:14 ` [PATCH v5 02/11] target/riscv: Don't overwrite the reset vector Alistair Francis
2020-05-28 22:14 ` [PATCH v5 03/11] target/riscv: Disable the MMU correctly Alistair Francis
2020-06-01 5:24 ` Bin Meng
2020-05-28 22:14 ` [PATCH v5 04/11] target/riscv: Don't set PMP feature in the cpu init Alistair Francis
2020-06-01 5:26 ` Bin Meng
2020-05-28 22:14 ` [PATCH v5 05/11] target/riscv: Add the lowRISC Ibex CPU Alistair Francis
2020-05-28 22:14 ` [PATCH v5 06/11] riscv: Initial commit of OpenTitan machine Alistair Francis
2020-06-09 13:48 ` Damien Hedde
2020-06-09 14:21 ` Philippe Mathieu-Daudé
2020-06-09 23:09 ` Alistair Francis
2020-09-08 14:52 ` Peter Maydell
2020-09-09 17:49 ` Alistair Francis
2020-09-09 19:00 ` Peter Maydell
2020-09-09 19:51 ` Palmer Dabbelt
2020-09-10 18:48 ` Alistair Francis
2023-05-19 17:15 ` [PATCH v5 6/11] " Philippe Mathieu-Daudé
2020-05-28 22:14 ` [PATCH v5 07/11] hw/char: Initial commit of Ibex UART Alistair Francis
2020-06-01 21:23 ` Alistair Francis
2020-06-02 11:22 ` LIU Zhiwei
2020-06-02 12:28 ` LIU Zhiwei
2020-06-02 17:54 ` Alistair Francis
2020-06-03 10:33 ` LIU Zhiwei
2020-06-03 15:56 ` Alistair Francis [this message]
2020-06-04 1:59 ` LIU Zhiwei
2020-06-04 4:35 ` Alistair Francis
2020-06-04 5:05 ` LIU Zhiwei
2020-06-04 5:46 ` Alistair Francis
2020-06-04 5:40 ` LIU Zhiwei
2020-06-02 17:46 ` Alistair Francis
2020-05-28 22:14 ` [PATCH v5 08/11] hw/intc: Initial commit of lowRISC Ibex PLIC Alistair Francis
2020-05-28 22:14 ` [PATCH v5 09/11] riscv/opentitan: Connect the PLIC device Alistair Francis
2020-05-28 22:14 ` [PATCH v5 10/11] riscv/opentitan: Connect the UART device Alistair Francis
2020-05-28 22:14 ` [PATCH v5 11/11] target/riscv: Use a smaller guess size for no-MMU PMP Alistair Francis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAKmqyKOvv2HCpXoD+8E5q2S7JqSDfT7_z3+_=cKFLi+H92itjw@mail.gmail.com' \
--to=alistair23@gmail.com \
--cc=alistair.francis@wdc.com \
--cc=bmeng.cn@gmail.com \
--cc=palmer@dabbelt.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-riscv@nongnu.org \
--cc=zhiwei_liu@c-sky.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).