--- Quote Start ---
I looked at the TS-7300 a while back. There was an
OpenCores.org design for the external bus interface. If Technologic Systems have used the same design for the TS-7400, you might get some nice tips in there. The code was written bu Jesse Off, one of TS's design engineers.
So your FPGA is attached to their board? Is this a PC104 module, or something like that?
So you have essentially taken the external processor bus and turned it into a bit-banged I/O bus. This is not exactly the most efficient way you could have done this, but lets put that aside for now, and get you something that will work. We can 'optimize' later.
--- Quote End ---
The TS7400 does not use a PC104 interface. It has this 20 bit DIO bus coming off their CPLD going to a 40 pin header (there are other useful signals in there like a SPI interface and a uart interface, but that is not interesting to our discussion). You can't connect to the cpu directly (which would have been way more efficient). As an aside, my next project is to design our own cpu board and then we can get much more efficiency.
--- Quote Start ---
You are interfacing to an
asynchronous bus, and the timing of that bus is slow compared to your FPGA clock (which with the use of a PLL can be ~100MHz).
To interface to this type of bus, you need to:
1) Use synchronizers (a chain of at least two DFFs) to synchronize the control signals from the TS-7400 board (ALE, RD and WR, but not the 8-bit data bus) to the FPGA clock domain.
2) You create an edge detector to detect when ALE pulses, and use that to capture the address into a register clocked by your FPGA clock.
3) You create a state machine that is triggered by the ALE pulse (in the FPGA clock domain), and use that to sequence the read or write cycle from the FPGA.
If I was writing this code, I'd create a bus functional model (BFM), which is just a fancy way of saying a simulation for the read/write accesses. I'd then simulate the logic in Modelsim to make sure I could read and write from some registers in my FPGA. Then I'd run some hardware tests and capture some SignalTap II traces to confirm that my BFM signals matched the hardware. Because your signals are all asynchronous, your .SDC file will cut the timing along those signal paths.
If this all sounds completely foreign to you, let us know, and Nial or myself, or someone else will give you code examples.
Cheers,
Dave
--- Quote End ---
My original efforts in designing for programmable logic started only about 2 months ago. I learn Quartus, Verilog, SystemVerilog, and how to write testbenches. At the time I thought timing would not be a factor because of the slow speeds. I can see now that timing is everything, it does not solve itself automatically, even in a simple slow design.
I had written testbenches for each of my modules all the way up to the final top level testbench. It does exactly what you suggest, emulates the bus, writing addresses, writing data, reading data and using approximately the same timing as I discovered on the scope. So the functional models have been working from the very early days, according to ModelSim. Not having a problem with that. When running on the FPGA then I discovered the problems with timing and registers not doing what ModelSim said they should.
I did in fact write a state machine for the main IO at the top level and it does what you suggested. It basically captures the address in a register during the ale pulse (I have been trying different suggestions on that to use it to gate the main clock so that all timing is based on the one 14 MHz clock). Those function correctly in the test bench.
I'm coming up to speed on TimeQuest and SDC files and the Timing Advisor. Following its suggestions I have been able to get the slack time to be positive in all but one signal and that one is off by only a couple picoseconds. but I have not tried that in the hardware yet.
Honored Contributor
