Project: rs232_syscon

People | Documentation | Download | OpenCores Mail list | Contact me

Description

rs232_syscon is a synthesizeable soft core that allows debugging of peripherals connected to a Wishbone type of bus. Specifically, it lets the user write and read registers, and send out reset pulses, via an rs232 serial connection to a "dumb terminal." (Such as windows "hyperterm"!) It is completely scalable through parameter settings, to accomodate address and data buses of any arbitrary size. Furthermore, the rs232_syscon module can share the Wishbone bus with the master (presumably a processor of some kind). It implements a handshaking protocol with the master to "request" the bus. When the master grants access, the rs232_syscon runs bus cycles on its own, to report contents of registers and memory back to the user, in an easy-to-read hexadecimal format. This is very useful when debugging peripherals -- you can set the contents of memory, set up registers, and even use registers to control "single stepping" of your target processor. If desired, the rs232_syscon can be the sole master of the Wishbone bus, to perform "human-speed" tests on peripherals (set a value, check a result) without having to connect the peripheral to a processor.

The "ack_i" and "err_i" signals of the Wishbone bus are used to determine if the bus cycles are correctly executed. The rs232_syscon module uses a "watchdog" timer to determine if "ack_i" has arrived too late, and if so, it sends an error indicator back to the host terminal. If "err_i" occurs, it also sends back a bus error indicator. The timeout value of the watchdog timer is configurable by parameters to whatever length is needed, and the bus cycles are automatically extended for as many clocks as needed until the "ack_i" signal is received. If "ack_i" is not used, simply tie it high.

The design team of rs232_syscon welcomes any kind of help and feedback on this core. If you are interested in further development of this project, please contact us.


Current Status:

In the future, a version could be implemented using a small microcontroller core with some integrated software, which would probably be more compact and flexible, with a richer command set. But, since we wanted to use this core to _develop_ microcontroller cores -- well, it was a case of "which came first, the chicken or the egg?" We had to start somewhere!

Next Steps:

Maintainer(s):

Mailing-list: