View email archives for the history of this mailing list.
systemc-forum - SystemC "UART"
- To: <systemc-forum@xxxxxxxxxxxxxxxxx>
- From: "Bradley, Mike" <mike_bradley@xxxxxxxxxx>
- Date: Mon, 10 Jan 2011 15:52:48 -0700
- Send Email to firstname.lastname@example.org:
- Send new message
- Reply to this message
We are looking to create a model of a system to boot an RTOS. For now,
the system is simple, just a CPU, memory, interrupt controller and UART.
The reason for the UART is to handle standard I/O (e.g. console)
interaction from the RTOS. Writing to the UART is not an issue, but
reading from the UART, has left us slightly baffled. First the basic
* CPU polls the UART to see if data has been received.
* If data is ready it is read from the receive buffer
* Go do some other stuff, and return to poll UART.
Now the issue, is how to get data into the UART? We have some
additional code which opens unix pipes to communicate with a program
running in an xterm. Presumably, the user types data into the xterm,
the program sends data into the pipe, and ...here is the issue:... the
UART needs to 'get' the data. Now, assuming just polling mode, when the
UART is polled, then it could check to see if there is any data in the
pipes. (OR maybe better, it could block until data is typed into the
UART) But, if the UART is in interrupt driven mode, we have a problem:
* CPU enables interrupts
* CPU does stuff, eventually just spinning in a loop waiting for
* Since the UART is not active, it never looks to the pipes to
see if data is available.... Failure....
To solve this, we could add a process (SC_THREAD) in the UART, that say
polls the UART every 10 microseconds, or so. The thread could then set
the interrupt pin high. But, this could adversely affect simulation
speed, and makes the simulation non-deterministic.
I was wondering if perhaps this could be solved with sc_spawn(),
sc_fork(), or maybe even pthread's to have process not glued to
simulation time poll the xterm and then set an sc_event when things
OK, I know what you're thinking "Why have the user type in data?
Instead just read a file, etc." Yes and I suspect we may end up there
once concepts are proven and accepted. What we are hoping to show is a
simulation environment that takes minimal changes to the RTOS/BSP for
Thanks in advance for some good advice,