Strange bus failure

It is most likely a problem with your design. A circuit cannot ~"forget" how to work.

Have you got a simulation test bench? did the results do as you expected?

Thanks for the reply. I didn't simulate the entire circuit, but I did simulate the components. They work. The compiler isn't generating any warnings that are useful.

Can bus names traverse files and cause a problem? For example, a sub circuit file with a wire named "in_p" and another unrelated wire at the top level also named "in_p". Will the compiler try to connect them?

What's happening here is like the bus isn't really connected at all. When the receiver is only connected to the display, it works fine. When I add the transmitter, neither the display nor the transmitter seem to get the correct values.

Likewise, if I connect the output of the receiver only to the input of the transmitter, it fails as well. The only time it works is when the receiver is connected only to the display.

The input pin on the transmitter is a different name than the bus, does that matter? Its physically connected with a bus line.

I can probably post an image of the screen if that will help?

Without the source, it will be difficult to diagnose

As long as the named nets are in different files, there should be no problem (if it was trying to connect 2 things to the same net, you'd get an error).

Is your design fully synchrnonous?

Everything is synchronous except for the main clock divider. This circuit generates the 1Hz clock and the refresh clock for the LED display. There have been no problems with it that I have noticed.

The RS232 transmitter and receiver are clocked with a baud rate generator which is a synchronous programmable 16 bit divider. This divider produces a 16X baud clock.

Oh, inside the transmitter is a /16 clock prescaler that is asynchronous. The main transmitter is synchronous and operates at the baud frequency. The receiver operates at BaudX16 frequency.

The 8 bit bus output of the receiver is effectively almost static. It only changes when a new character is received. The LED display does not buffer the input buses (there are four 4 bit buses) and displays the instantaneous contents of those buses.

There is a split when it goes into the display buses. The display circuit has a 4 bit bus for each digit. There are four digits. The main 8 bit bus comes from the receiver and is named "D[7..0]" and the display branches are named "D[3..0]" and "D[7..4]". The named 4 bit buses are physically connected to the named 8 bit bus. The other two digit buses are tied to ground to produce zeros on their respective digits. Again, this works fine until I connect the transmitter.

The transmitter has an 8 bit register that gets clocked by a WR pulse. The WR pulse also triggers the transmitter circuit to begin. There doesn't seem to be a problem with the WR strobe. I have used both the 1Hz clock for this and also the RX_READY line from the receiver with the same results. Characters are being transmitted at the right time, they just aren't the correct characters.

My guess, based on the way its acting, is that somehow some of the bus is not connected. In one compile, the transmitter would echo the same character sent, but with bit 4 forced low. Why would it connect some bits, but not the others?

I can upload a screen shot or the entire design if you think it will help. It will be later this evening though.

I wanted to clean up the project a bit before posting and there was an Altera stock component 74163 that was written in HDL. Since I wanted my project to be in all schematic, I replaced their 74163 with one that I drew up myself.

The problem is that doing that seems to have fixed the bus problem at the top level. The Altera HDL 74163 was several levels down and had nothing to do with the receiver circuit. The receiver circuit already had the new 74163 circuits.

Anyhow, I'm not sure just how much debugging is going to be possible since its working now, but I would like to know what is causing this.

Could the compiler be upset when schematic and HDL are mixed? Perhaps a bug where they don't get along?

HDL and schematics mix just fine, and it is highly recomended that you do all of your design in HDL (because it is easier to store in a revision control, easier to simulate, more portable etc).

The problems in the design are probably much to do with the logic generated clocks. Creating clocks with logic (even slow ones) is not recomended. You can get all sorts of problems because they are highly affected by routing, tempurature, voltage and they are not checked by timing analysis.

You need to use the same 48MHz clock for the whole system, and generate clock enables instead of actual clocks.

HDL has some advantages, but Schematic is not without advantages itself. The main advantage is that I can draw a schematic, but I don't yet understand how to write HDL code (although I can read it a little bit).

I don't understand what you mean by substituting clock enables for actual clocks. The design needs clocks at a particular frequency - especially the baud clock. The uart synchronously clocks off that and not the 48Mhz. It simply wouldn't be practical to try to make it work at 48MHz.

However, it is possible that the problem I am experiencing is the baud rate generator failing rather than the bus. I'm not sure how since its just a big 16 bit counter (synchronous to 48 MHz).

I drew up an 8 digit frequency counter that I can use to test the output of the baud rate generator. I'll reinstall the stock Altera HDL 74163 and see if the problem returns. The HDL is most likely altering the routing, but it shouldn't cause the routing to silently fail (there were no compile errors).

I'll post my results later.

Ok, I did some further testing.

I confirmed that I can replicate the problem reliably by replacing my 74163 with the stock HDL 74163. From the design I last posted, replacing the 74163 in UartSend with the Atlera stock 74163 will make it fail as I mentioned in the OP.

I put my 74163 back in and inserted the frequency counter that I drew (which is a proven design) and it falsely reads 40X the baud rate, not 16 like it should. The echo'ed characters are correct for some, but not all. For example, pressing Shift-S echos "s" and pressing just s echos 's' as well. So by this, I can conclude that the frequency counter circuit is failing and the baudX16 clock is obviously correct.

Now when I swapped the 74163 again and used the stock HDL version, now everything works - frequency counter, baud generator and character echo. The display is connected to the frequency counter in this configuration.

This is clearly some kind of routing error on the part of the compiler.

Interestingly enough, I do have a small amount of HDL code in the frequency counter. I got lazy and used a stock HDL multiplexer instead of drawing it out myself. Also, the baud rate generator has an HDL constant.

I'm starting to wonder if the number of HDL circuits matters - odd works, even doesn't. I might see if I can replicate this with simpler circuitry and submit it to Altera as a bug.

This is not a bug. This is your circuit using logic clocks.

Like I said, user generated clocks are affected by compilation - sometimes you'll get lucky and the routing works, sometimes you wont and the delay is too much. This is why you must use clock enables - they garantee that all signals arrive at the correct time and you'll never get differences between compiles.

HDL or schematic does not affect the RTL diagram (look at the RTL schamtic - tools -> netlist viewers -> RTL view). It will be the fitter changing the routing between compiles. The fitter seed is affected by the source. If the source changes even slightly, all the routing will be different.

I highly suggest you learn HDL.

Schematic pros:

- You get a schematic (this is only a pro if you like them)

Schamtic cons:

- You cant do diffs on them in a version control tool to see whats changed between versions

- You cant simulate them directly

- Not portable to other non-quartus tools