Connecting FTDI FT245R to clockport

[strim]

Hello.

I'm trying to build a simple Amiga-PC interface using FT245R chip and CoolRunner II CPLD. Unfortunately, I'm still a VHDL noob and my interface is not working very well.

I wrote a VHDL module looking like this. Reading data from FT245R FIFO is implemented in naive way but works correctly.

Writing appears to work at first, but there are weird transmission errors, which occurs only when byte values are changing, for example:

Amiga -> PC
0x72 -> 0x72
0x72 -> 0x72
0x72 -> 0x72
0x71 -> 0x73
0x71 -> 0x71
0x71 -> 0x71
0x72 -> 0x73
0x73 -> 0x73
0x66 -> 0x66
0x66 -> 0x66
0x44 -> 0x46
0x42 -> 0x42
0x40 -> 0x78
0x38 -> 0x3e
0x36 -> 0x36
0x34 -> 0x34

If I'm trying to send the same byte all the time there are no errors. For some reason it occurs only when byte values are changing...

Any ideas?

[Stedy]

Hi,

You need to connect your VHDL signals to the I/O pins.
Adding iord, iowr and cs to the sensitivity lists of your processes will help wake them up.

What toolset are you using?

Xilinx ISE will not synthesize your code, ERROR:Xst:528 - Multi-source in Unit <clockportFifo> on signal <fifoRd>; this signal is connected to multiple drivers.

It's past my bedtime, will lok again when rested.

Ian

[strim]

Originally Posted by Stedy

Hi,

You need to connect your VHDL signals to the I/O pins.
Adding iord, iowr and cs to the sensitivity lists of your processes will help wake them up.

Since cpWrite signal is derived directly form CS and IOWR, do I really need to add these signals separately into sensitivity list?

What toolset are you using?

Xilinx ISE WebPack 14.3 Linux64

Xilinx ISE will not synthesize your code, ERROR:Xst:528 - Multi-source in Unit <clockportFifo> on signal <fifoRd>; this signal is connected to multiple drivers.

Argh, sorry, I've managed to post an older version that doesn't even compile. Here's the full, working (well, at least compiling) source.

[RedskullDC]

Hi Strim, Stedy, et al.

Originally Posted by strim

Since cpWrite signal is derived directly form CS and IOWR, do I really need to add these signals separately into sensitivity list?
...
Argh, sorry, I've managed to post an older version that doesn't even compile. Here's the full, working (well, at least compiling) source.

I can't see that you need to add CS and IORW to the sensitivity list.
As you say, cpWrite is directly derived from them.

Looking at the write process:

-- handle write to clockport
process (cpWrite, address)
begin
fifoData <= "ZZZZZZZZ";
fifoWr <= '1';
if cpWrite = '0' and address = "0001" then -- 0xD80005
ctrlFifoRd <= data(6); -- update control register (just FIFO read signal)
elsif cpWrite = '0' and address = "0010" then -- 0xD80009
fifoWr <= '0';
fifoData <= data;
end if;
end process;


It looks to me as if you are setting the state of fifoWr incorrectly.

The WR signal input to the 245 is active high, and sampled on the falling edge (see attached pic).
The #RD signal input to the 245 is the other way around. (active low, and sampled on the rising edge).

Write signal to the 245 should be inverted:

-- cpWrite <= 1 when Amiga CPU writes to clockport
cpWrite <= '1' when cs = '0' and iowr = '0' else '0';

----

fifoWr <= '1';
if cpWrite = '0' and address = "0001" then -- 0xD80005
ctrlFifoRd <= data(6); -- update control register (just FIFO read signal)
elsif cpWrite = '0' and address = "0010" then -- 0xD80009
fifoWr <= '0';

In the section above, since you have the WR inverted, when you do a write to the control register, it leaves fifWr high.
In effect, it's sending a phantom write to the 245. == random crap written.

Change the write section to: (after altering the cpWrite derivation above).

-- handle write to clockport
process (cpWrite, address)
begin
fifoData <= "ZZZZZZZZ";
fifoWr <= '0';
if cpWrite = '1' and address = "0001" then -- 0xD80005
ctrlFifoRd <= data(6); -- update control register (just FIFO read signal)
elsif cpWrite = '1' and address = "0010" then -- 0xD80009
fifoWr <= '1';
fifoData <= data;
end if;
end process;


This will leave fifoWr low when you are writing to the control register, and the correct states when writing to the 245.

All theoretical, I haven't tested your code on real hardware

Hope this helps,
Red

[strim]

Hi guys!

All theoretical, I haven't tested your code on real hardware

Thanks, you've helped me greatly by pointing out that fifoWr should be active high! Now after correcting the state of fifoWr I have reliable writes working (or so it seems).

I think that you've misunderstood the cpWrite signal. It's not passed to the FT245 chip at all, it's only used internally to check when there is write on clockport occurring. And data on lines from clockport is valid only when this signal is low. Just out of curiosity I tried changing it as you have suggested, but then write didn't work at all.

Since we're discussing this I'd like to get your opinion on one more thing. I've mentioned that reading is done in a very naive way now. FT245 chip has a pin that is active low when there is data in receive buffer ready to be read (fifoRxE in my code). Currently I'm just passing value of this signal in control register. There's also separate line that controls reading data from FIFO buffer (fifoRd). Now I'm also controlling this line via register (ctrlFifoRd signal). So now on Amiga to read data from FIFO I have to do:

- read the state of fifoRxE, it's active low if there's data in FIFO waiting
- if 0 then set ctrlFifoRd to 0
- (now fifoData contains valid data, so it appears on clockport data pins)
- read data from clockport to Amiga's memory
- set ctrlFifoRd to 1 (which changes fifoData to high impedance and prepares the next byte in FIFO to be read)
- repeat

I wonder if it's possible to automate the fetching data from FIFO in VHDL, so on Amiga I'd just check fifoRxE and if it's low then read the clockport? I'd like to pull fifoRd low automatically when there's read occurring on clockport and then set it to high after the read is done.

Best regards,
strim

[RedskullDC]

Hi Strim,

Originally Posted by strim

Thanks, you've helped me greatly by pointing out that fifoWr should be active high! Now after correcting the state of fifoWr I have reliable writes working (or so it seems).

I think that you've misunderstood the cpWrite signal. It's not passed to the FT245 chip at all, it's only used internally to check when there is write on clockport occurring. And data on lines from clockport is valid only when this signal is low. Just out of curiosity I tried changing it as you have suggested, but then write didn't work at all.

...
I wonder if it's possible to automate the fetching data from FIFO in VHDL, so on Amiga I'd just check fifoRxE and if it's low then read the clockport? I'd like to pull fifoRd low automatically when there's read occurring on clockport and then set it to high after the read is done.

I realised after I switched the computer off that there wasn't any need for the change to the cpWrite signal. Flipping the value of the signals in the write process was sufficient.
Sorry for the bum-steer.
In my defence, it was past midnight when I posted that
(Way past bedtime as Stedy put it...).

----

Not sure why you use the ctrlFifoRd signal at all?
You could just set the fifoRd signal in the "read" process.
(in a similar fashion to fifoWr in the "write" process).

My only concern would be the lack of hold time on the 245's read output of 0ns. I don't have a timing diagram of the *IORW and *IORD signals on the Amiga in relation to the the *DSACK signals, but I don't think it would be an issue.

I've attached a pic of the modded vhdl, plus a simple "c" code fragment to control it.

You didn't say whether you were using 68K ASM or C/C++ to control it, so I hope the C code makes sense to you?

Cheers,
Red

[strim]

Originally Posted by RedskullDC

I realised after I switched the computer off that there wasn't any need for the change to the cpWrite signal. Flipping the value of the signals in the write process was sufficient.
Sorry for the bum-steer.

No problem at all .

Not sure why you use the ctrlFifoRd signal at all?
You could just set the fifoRd signal in the "read" process.
(in a similar fashion to fifoWr in the "write" process).

My only concern would be the lack of hold time on the 245's read output of 0ns. I don't have a timing diagram of the *IORW and *IORD signals on the Amiga in relation to the the *DSACK signals, but I don't think it would be an issue.

I've tried similar solution before and it doesn't work correctly. That's why I "invented" the ctrlFifoRd to control FIFO read signal manually. I should have mentioned this.

Now with read process modified according to your suggestion:
If I send 4 bytes from PC: 0x61 0x62 0x63 0xA
On Amiga I only get: 0x61 0x63 0xA

And sometimes the values on Amiga side are even weirder, so I suspect that there's some timing problem? I don't have any timing diagrams for clockport, but you can find a timing diagram for SUBWAY (which is a clockport device) in it's manual.

You didn't say whether you were using 68K ASM or C/C++ to control it, so I hope the C code makes sense to you?

Thanks, I'm using C and already have some code written. But that's not a problem, I'm pretty fluent in C. It's only VHDL that's like magic to me .

[RedskullDC]

Hi Strim,

Originally Posted by strim

Now with read process modified according to your suggestion:
If I send 4 bytes from PC: 0x61 0x62 0x63 0xA
On Amiga I only get: 0x61 0x63 0xA

And sometimes the values on Amiga side are even weirder, so I suspect that there's some timing problem? I don't have any timing diagrams for clockport, but you can find a timing diagram for SUBWAY (which is a clockport device) in it's manual.



Thanks, I'm using C and already have some code written. But that's not a problem, I'm pretty fluent in C. It's only VHDL that's like magic to me .

I can't see any problems in the timing. the FT245 easily meets the bus cycle requirements.

Do you disable interrupts before reading the control reg, and re-enable after reading the data reg?
Do you have any interrupt routines running that may be scanning the clock port addresses?

Could you post your C code?

Cheers,
Red

[strim]

Do you disable interrupts before reading the control reg, and re-enable after reading the data reg?
Do you have any interrupt routines running that may be scanning the clock port addresses?

I didn't disable interrupts, but if it was a problem caused by interrupts, then it would probably also occur earlier (when I was using read method with manual fifoRd changing).

Besides, I'm pretty sure that there are not such interrupt routines running, as it is a clean AmigaOS 3.1 installation.

Could you post your C code?

I've imported everything into my GitHub account.

But I can also reproduce this problem by peeking the FIFO address using peek command from peek_poke package (works just like peek command on 8-bit machines). So I guess that my code is OK .

[RedskullDC]

Hi Strim,

Originally Posted by strim

But I can also reproduce this problem by peeking the FIFO address using peek command from peek_poke package (works just like peek command on 8-bit machines). So I guess that my code is OK .

If you try multiple passes of the program with the same data, does it always drop/substitute the same bytes?

Only thing (potentially) missing in your code that I can see is the "volatile" keyword on the address pointer.
Unlikely, but compiler could try to optimise it somehow....

Be interesting to see the 68K asm your compiler produces..

Cheers,
Red

[strim]

Originally Posted by RedskullDC

If you try multiple passes of the program with the same data, does it always drop/substitute the same bytes?

It is different every time. Sometimes data received resemble what was sent, but on the other times it is completely random. Personally, I still think that the problem lies somewhere in VHDL code.

Even doing it [ Show youtube player ] works . Here I'm flipping fifoRd using switch - no problem at all. Second LED shows state of fifoRxE. 7-seg display is connected directly to fifoData pins.

Only thing (potentially) missing in your code that I can see is the "volatile" keyword on the address pointer.
Unlikely, but compiler could try to optimise it somehow....

I've added volatile, but it didn't change anything.

Be interesting to see the 68K asm your compiler produces..

Here you go . I don't see anything wrong.

[RedskullDC]

Hi Strim,

Originally Posted by strim

It is different every time. Sometimes data received resemble what was sent, but on the other times it is completely random. Personally, I still think that the problem lies somewhere in VHDL code.

Even doing it [ Show youtube player ] works . Here I'm flipping fifoRd using switch - no problem at all. Second LED shows state of fifoRxE. 7-seg display is connected directly to fifoData pins.

I've added volatile, but it didn't change anything.
Here you go . I don't see anything wrong.

I was doubtful that volatile would make a difference on 68K.
Often does on multi-core x86 cpu's though. Your code looks fine to me.

The fact that it's random, and works when you do it by hand makes me keep thinking about that lack of any hold time on the 245 output.

Try holding the cpRead signal active until the *CS signal disappears.
Check the attachment to see what I mean.

It's possible that the xilinx tools won't let you compile that, since one case is level related, and the other is clocked.
Also possible that the Coolrunner chip's logic blocks can't do that.
(I'm an Altera fan ).

Hope this helps?
Red

P.S.
I've attached a file you might find interesting. Something along the same lines I did a while back.
An altera MAX based board which was a plugin replacement for a 6551 UART in an apple2. Makes the FT245 look like a 6551.

[strim]

Originally Posted by RedskullDC

The fact that it's random, and works when you do it by hand makes me keep thinking about that lack of any hold time on the 245 output.

Try holding the cpRead signal active until the *CS signal disappears.
Check the attachment to see what I mean.

It's possible that the xilinx tools won't let you compile that, since one case is level related, and the other is clocked.
Also possible that the Coolrunner chip's logic blocks can't do that.
(I'm an Altera fan ).

It did compile, although it still doesn't work . Looks like behaviour is the same.

I'm confused . I've also managed to break writes again in the process.

Maybe I'm reading data too early? Read timing diagram for FT245 suggests there's at least 20ns delay between fifoRd change and valid data? CS is held low for around 95ns. I'm not sure about that but I suspect that data is actually read from clockport when iord changes from low to high.

Or maybe it would be better to implement FIFO read control in some kind of finite state machine? For example: on falling_edge(iord) change fifoRd to 0, wait for some time, access fifoData pins, on rising_edge(cs) change fifoRd back to 1?

Sigh, I shall learn more VHDL before attempting such project. Although earlier I've created an Amiga-PC interface using microcontroller present on this CoolRunner II starter board and had no such problems.

P.S.
I've attached a file you might find interesting. Something along the same lines I did a while back.
An altera MAX based board which was a plugin replacement for a 6551 UART in an apple2. Makes the FT245 look like a 6551.

That's pretty cool!