Our great sponsors
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
Looking over your serial port design, it looks you are struggling to get your UART to work. Has it seen hardware?
For example, some time after I built my own first serial port transmitter and receiver, someone tried using them in composition: A host (i.e. PC) would transmit a bunch of data, get received by the FPGA, processed by the receiver, and then the data would be sent back to the host via the transmitter. This is a hard test to get right, and my own design failed at the task. (It only returned every other byte!) What I learned from this is that the transmitter must take exactly (10*BAUD_CLOCKS) to transmit a byte. That also means that READY must be high on the last clock cycle of the byte to avoid falling behind. Let's just say that my own serial port wasn't (initially) up to the task. Among other things, the serial port receivers output "VALID" was only one cycle long, and didn't get latched anywhere if the transmitter wasn't ready for it. As I recall, we spent many days scratching our heads at the problem. Eventually, the person using my FPGA switched his host to sending 2-stop bits and things started working. Later, and only a long time later, did I ever find the off-by-one bug in the STOP bit state. My point? Serial port composition is an exacting test, and therefore a good one to work with. You ought to try it.