To get the current release's synchronous output mode working, you must do an initial PINSETY before releasing reset (DIR high). Once DIR is high, you can immediately give it another word with PINSETY. After that, do another PINSETY after each IN raise and PINACK. That will keep the output buffer full at all times.
I think I've got the new serial mode finished for the smart pins.
It supports 15-bit N-clock and NCO baud rates in async modes and its word length is settable from 1..32 bits.
The async modes work up to clock/2, though it's certainly at the edge. Clock/3 should be quite safe, though.
I'm confirming that the sync modes are okay now. You can select sample positions of 1 or 2 clocks before the clock edge.
Wow, Great, sounding very flexible now
Async to /2 would realistically only be used in RX with a companion CLK, such as in the FTDI Fast Serial mode, but it is important to be able to operate to that.
I presume you can start/stop a CLK pin, and Serial RX in known phase ?
Tx to /2 might be used for asymmetric clocked designs - because P2 can support pretty much any baud, remote slave P2's could run at lower power Clock speeds, to a higher speed clocked HUB.
I guess Tx to /1 could even be useful in that case ?
Have you looked at the sustained speeds issues in the 8-25-50MBd regions ?
Ozpropdev's tests suggested 3 stop bits added, at 8MBd
Jmg, I'm not sure what you mean about starting and stopping the clock during RX. Of course, during synchronous transmit and receive, new bits are only output and input around the particular clock edge.
To get the current release's synchronous output mode working, you must do an initial PINSETY before releasing reset (DIR high). Once DIR is high, you can immediately give it another word with PINSETY. After that, do another PINSETY after each IN raise and PINACK. That will keep the output buffer full at all times.
Great, so there is already what some might call a small FIFO, allowing queued data to always be ready for immediate next-load, on Tx_Done.
Jmg, I'm not sure what you mean about starting and stopping the clock during RX. Of course, during synchronous transmit and receive, new bits are only output and input around the particular clock edge.
In the FTDI Fast Serial mode, their variant on faster Serial links, it connects to P2 like this :
The Prop gives the FT chip a CLK up to 50MHz.
Async framed data (Start+9 bit+Stop) comes out of the FT chip, with that Clock, and if the Prop is busy, it pauses that CLK, which then stops FT data streaming.
Because the Data is Async Framed (Start & Stop bits) but also has a CLK, I think P2 can manage this with by using 3 Smart pins.
1 x CLK, usually ON, but can be paused if the P2 needs to handshake the FT device.
1 x Async RXD, 9b Changes on CLK _/=
If Async is ok to SysCLK/2, this should be good to 40MHz on FPGA.
1 x Async TXD, FT samples on CLK _/= (13-14b?, see below)
The CLK and RX,TX need to be stable and known phase and when the CLK is paused it needs to resume in that same phase.
For P2 -> FT handshake, there is a FSCTS line that can be polled, & FWIR from tests I did on this a while ago with PLDs, I found the diagram showing a delayed release of FSCTS is correct, as is the statement "An external device is allowed to send data into the FT2232H if FSCTS is high."
Those two combine to need a modest delay between bytes - 13~14 Clocks per byte, anything less is not ok.
P2 could manage that either
a) with WAITPIN on FSCTS, but that may interact with the FIFO, or
b) it could set Tx length as 13 or 14b, and pack bytes closer, in packets.
(handshake is no longer bit-level timed)
Sounds to me from your posts, that the next build can talk to a FT232H at 40MHz, FT Frame limited speed.
It should also talk to Pi3 at PI's silicon limits of 25MBd/N (400MHz ) or 15.625MBd/N (250MHz )
Well, actually P2 can talk to a LOT of FT232H or Pi3's, if anyone needs to
To get the current release's synchronous output mode working, you must do an initial PINSETY before releasing reset (DIR high). Once DIR is high, you can immediately give it another word with PINSETY. After that, do another PINSETY after each IN raise and PINACK. That will keep the output buffer full at all times.
Chip
I made these changes to my code and see no change.
Data is misaligned and every second PINSETY is ignored.
My workaround is to clock the sync transmitter with 7 clocks after initial smartpin setup.
After that all PINSETY instructions work fine.
Here's the output without my workaround. Data shows as $E4 not $72
I setup two smartpins as sync, byte transmitters.
DATA2 is setup with a PINSETY #$40 before DIRA is enabled.
Then 7 clocks are sent to align the transmitter..
DATA is setup the same except for the 7 clocks.
Two bytes are then sent to both smartpins ($7E,$81)
The first byte sent by the DATA pin is the left shifted $40 followed by the left shifted $7E byte.
The DATA2 pin sends the correct bytes in the right bit positions.
It seems if the transmitter is not "aligned" the byte is left shifted and one byte behind were it should be.
The captured traces show the results.
Comments
Jmg, I'm not sure what you mean about starting and stopping the clock during RX. Of course, during synchronous transmit and receive, new bits are only output and input around the particular clock edge.
Great, so there is already what some might call a small FIFO, allowing queued data to always be ready for immediate next-load, on Tx_Done.
In the FTDI Fast Serial mode, their variant on faster Serial links, it connects to P2 like this :
The Prop gives the FT chip a CLK up to 50MHz.
Async framed data (Start+9 bit+Stop) comes out of the FT chip, with that Clock, and if the Prop is busy, it pauses that CLK, which then stops FT data streaming.
Because the Data is Async Framed (Start & Stop bits) but also has a CLK, I think P2 can manage this with by using 3 Smart pins.
1 x CLK, usually ON, but can be paused if the P2 needs to handshake the FT device.
1 x Async RXD, 9b Changes on CLK _/=
If Async is ok to SysCLK/2, this should be good to 40MHz on FPGA.
1 x Async TXD, FT samples on CLK _/= (13-14b?, see below)
The CLK and RX,TX need to be stable and known phase and when the CLK is paused it needs to resume in that same phase.
For P2 -> FT handshake, there is a FSCTS line that can be polled, & FWIR from tests I did on this a while ago with PLDs, I found the diagram showing a delayed release of FSCTS is correct, as is the statement "An external device is allowed to send data into the FT2232H if FSCTS is high."
Those two combine to need a modest delay between bytes - 13~14 Clocks per byte, anything less is not ok.
P2 could manage that either
a) with WAITPIN on FSCTS, but that may interact with the FIFO, or
b) it could set Tx length as 13 or 14b, and pack bytes closer, in packets.
(handshake is no longer bit-level timed)
Sounds to me from your posts, that the next build can talk to a FT232H at 40MHz, FT Frame limited speed.
It should also talk to Pi3 at PI's silicon limits of 25MBd/N (400MHz ) or 15.625MBd/N (250MHz )
Well, actually P2 can talk to a LOT of FT232H or Pi3's, if anyone needs to
That's quite impressive.
You could maybe do a new serial modes release, to allow parallel testing of the new serial features while you wrap USB ? (unless USB is very close )
+1
(Even if it's just for the A9 board for the interim release.)
I made these changes to my code and see no change.
Data is misaligned and every second PINSETY is ignored.
My workaround is to clock the sync transmitter with 7 clocks after initial smartpin setup.
After that all PINSETY instructions work fine.
Here's the output without my workaround. Data shows as $E4 not $72
DATA2 is setup with a PINSETY #$40 before DIRA is enabled.
Then 7 clocks are sent to align the transmitter..
DATA is setup the same except for the 7 clocks.
Two bytes are then sent to both smartpins ($7E,$81)
The first byte sent by the DATA pin is the left shifted $40 followed by the left shifted $7E byte.
The DATA2 pin sends the correct bytes in the right bit positions.
It seems if the transmitter is not "aligned" the byte is left shifted and one byte behind were it should be.
The captured traces show the results.
That seems sort of consistent with Chip's buffer comments above ?
Perhaps Chip can post his test code examples, one per thread, along the lines of
* Async Self Loopback, packets sent, one COG sends, another COG Tx, highest Silicon speed.
* Async Self Loopback, packets sent, one COG doe both Tx & Rx,, highest Silicon speed.
Repeat for Sync, and also
* Async remote Loopback - for PC tests, COG just echos what came in.
Handshake options may need to come into play
* FTDI Fast Serial Mode, as above. Test to 40MHz ?
Then those can be edited to push into the corner cases ?