The stock CHOCHI board has the serial port here:


To output a character:



To input a character,

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

The first iteration of CHOCHI hardware (pre-update) had a toggle-style LED. Reading it toggled the state, so something like


The update changed the $C000 port so that the low bit output sets the LED. Now you have to store a $00 or a $01 to $C000 to set or reset the LED. Reading the port does not return the status of the LED (I did not think it's worth adding another mux and slowing down the system).

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Because the 6502 core allows 1 cycle for a read, you can avoid muxes in critical path. Suppose you have 3 peripherals (PA, PB,PC), and RAM and ROM. Instead of doing DI = MUX( PA, PB, PC, RAM, ROM) you can do DI = MUX( P, RAM, ROM ), where P is a common peripheral register, and you set P <= MUX( PA, PB, PC ).

And of course, you can use wired or instead of a mux, and make sure all unselected inputs are 0.

You are right, it should be fine. I've had a hard time bringing the system clock up, so now I am afraid to mess with it too much. I have to rethink the IO anyway.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Advantage of the wired-or method is that you can often use reset inputs. Both BRAMs and regular FFs have special reset inputs that you can use to produce zero output value without using additional LUTs. See www.xilinx.com/support/documentation/wh ... /wp275.pdf‎

What do you mean by wired OR? I didn't think Spartan3 supports true wired OR. Do you mean just a 4-way OR gate connecting 4 different sources and making sure that the unused ones are set to 0? This is the way I do it now - the data in is a 4-way or gate connecting SRAM, input port, UART and BRAM. I did not want to add another layer of logic, but you are right, there is plenty of time available. And it's not really two layers of logic as both layers are triggered simultaneously. I am just a wussy.


The only truly 'wired' way I can think of is routing the signals out of the chip, connecting them together and bringing them back in. This board does not have enough IO pins to do that. That reminds me of an amazing demo I saw on the Propeller board. The guy whose name escapes me used the IO pins as a data bus to connect several cores together for a really fast interconnect (the normal way to communicate between cores is to write data in a common RAM and have the other core read it which takes tens of cycles)

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

I mean using the verilog 'wor' keyword. It's only a wired-or in the source code, but it allows you to add multiple sources to the same bus without having to manually add an or-gate. In modern FPGAs it's all synthesized to a regular OR, of course.

Actually, I am even more concerned about the address decoding logic, which involves wider gates. Right now, I have:

So there is an 8-input LUT to match C0xx, followed by 6-input LUTs for individual selects, before the IO units get their select signal. That seems excessive, but I haven't been able to think of a better way.

Worse yet, I select the BRAM like this:

And finally the SRAM for everything else:

That does not make me happy. I suppose it would be wiser to dedicate logic to SRAM selection - that may be why 45MHz is the top speed for now.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Yes, those are wide logic functions, but it's not necessarily a problem. When the CPU reads, you can (must) add a register in the path, so there's only a little bit of logic from address bus -> select decoding -> reset input. Usually that's a shorter path than memory->ALU.
When the CPU writes, usually the data goes into a register, so it's fairly short too.

Pardon my ignorance, but I've never used 'wor'. How would my code look with it? The examples online are confusing. I must be missing something. For instance,
seems much less readable then

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

I guess it doesn't matter too much since the SRAM is always selected in my system, so it is only the input mux that incurs any delay. The SRAM write signal may be more of an issue... No, I just write the SRAM for every CPU write - data written to IO is also written to the SRAM but there is no harm done as it's ignored on read anyway.

Interesting - this creates shadow registers for IO writes. All I have to do is disable output ports on read so that the SRAM is read to get the current values of output ports (solving the LED output status read for one)

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

But something like this is pretty readable:

Would this work?

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Yes. That's the idea.

And you can add more devices without having to create additional temporary signals, and extending the wide OR.

Well, this has been most productive. Learned a new trick, and figured out how to read the current value of the output ports...
Thanks, Arlet!
EDIT: Not having to remember to place new IO units into the mux is a great abstraction (on the other hand, it's harder to tell how many signals are being or'ed...)

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut