Prop123_A9_Prop2_v7y Intermediate Release - 14 March 2016 - Faster PINSET, all shift modes LSB-first
cgracey
Posts: 14,133
This is the 2nd intermediate release of the new serial modes in the smart pins, here is v7y for the Prop123-A9 FPGA board:
https://drive.google.com/file/d/0B9NbgkdrupkHM0wxYUlzb3dFZGs/view?usp=sharing
The Google Doc has been updated at the end to cover the new serial modes:
https://drive.google.com/open?id=10qQn_-B7avY2ce0N1MDDdzOF1lACPNWUJkjHFyzITiY
P.S. This v7y .rbf file only has four cogs, not 16. It has 64 smart pins, though.
https://drive.google.com/file/d/0B9NbgkdrupkHM0wxYUlzb3dFZGs/view?usp=sharing
The Google Doc has been updated at the end to cover the new serial modes:
https://drive.google.com/open?id=10qQn_-B7avY2ce0N1MDDdzOF1lACPNWUJkjHFyzITiY
P.S. This v7y .rbf file only has four cogs, not 16. It has 64 smart pins, though.
Comments
Ah, I'm glad to see you saw this so quickly!
I think when you read the new docs about how the serial modes work now, you'll feel more settled than before.
I thought about how you would probably like this to work when I made the improvements.
%1010000000000_0_1_00000_1
This will be necessary for getting video working, again.
Did you do any sustained serial transfer tests, (one way & loop-back) at the upper baud rates ?
Yes. I believe everything works at clock/3 without a common clock signal.
Can that now continually Tx and/or Rx in SW bursts, with a single stop bit (stable) between bytes ?
Absolutely!
NCO baud generator in async. transmitter works nice @ 12M baud on FT2232H.
Edit: Sending 384k chunks @ 12M baud in 327mS using "buffer full" checks. Cool!
Super! Thanks for trying that out.
Now, we've just got to get the USB done.
I have two smartpins set up as sync. transmitters with a common clock.
One pin has an inverted clock input and the other normal clock input.
This works fine as can be seen in the first image (oz1.jpg).
If I then swap the clock inversion around, the pin with a negative relative input pin (DATA2) goes out pf sync. (oz2.jpg)
Wouldn't that be because one pin is clocking the 2nd bit out before the other is clocking the 1st bit in? Remember that the first clock on the transmitter causes the 2nd bit appear, while the last clock causes the first bit of the next word to appear.
Sounds great.
384k*10/12M = 0.32s
It you have a frequency counter, and stream 0x55, what does that measure ?
If you reconfigure the FT2232H to Fast Serial, it can still use VCP, and then you should be able to run 10/20/40MHz, to around these numbers ?
384k*13/40M = 0.1248s
or
384k*14/40M = 0.1344s
P2 Generates continual CLK on one pin -> FSCLK, Checks for FSCTS=1, and sends Std Async Data stable on the _/= (Data updates on =\_)
It may be faster to config as 13-14 bits TX length (whatever the shortest time FT2232H supports), but simple 8 bit + handshake should work too.
Expanding on my earlier post,
From the P2 V7x docs:
In my configuration both smartpins are transmitting the same byte.
The only difference between the two is is one is clocked on pos edge clock and the other is clocked on neg. edge.
The following smartpin config produces the correct output (oz3.jpg)
but simply swapping the clock polarity on both fails on neg edge clock (oz4.jpg) Hope this makes sense.
Cheers
Brian
Trying to get the Baud formula, and I think with NCO, you need to work by overflows in the 10 Bit times, which comes to
7+7+6+7+7+6+7+7+6+7 = 67 SysCLKs
Predicted time is
384k*67/80M = 0.3216s
Does a frequency counter measure 5.970149 MHz, when streaming 0x55's ?
AutoBaud extraction can give slightly differing values, depending on what it samples.
If it samples over 8 bit times, that gives
8/((7+6+7+7+6+7+7+6)/80M) = 12.075472 MBd
or if it includes Start-bit (less common, as that needs /9)
9/((7+7+6+7+7+6+7+7+6)/80M) = 12000000
That varies slightly from the FreqCtr value.(which times to include Start & Stop bits)
It looks like the failing case is seeing some clock, since it eventually transitions. Maybe it has the wrong data? I will run your test cases in the morning.
It looks like when the data finally transitions, it's maybe the first bit of the $C4 value. Perhaps it doesn't load the $C4 value until it exhausts an initial zero value it had, for some reason.
I found the problem (me).
It was caused by me initializing one of the sync. transmitters before initializing the clock smartpin.
This was causing a single edge detect on the neg edge configured smartpin, thus messing up the works!
Sorry for the false alarm.
Cheers
Brian
Okay. No problem. Glad we know what the trouble was.
I setup a Ft2232H in fast serial mode and the best speed I could achieve was ~15M baud. (384k took 262mS).
I configured a smartpin in transition mode and fed the data out using a sync. transmitter.
The smallest transition clocks value I could use was 2 clocks. (20Mhz clock).
One limiting factor is the instruction overhead needed to format the data before passing it to the transmitter. Just this snippet adds ~30mS to the total time.
Another limiting factor is the sync. transmitter takes 2 clocks to shift the data out after an edge which is probably why 40Mhz can't be achieved.
I think I prefer the standard rs232 mode @ 12M over two channels.
With today's new and improved REV instruction, there is no longer any shift compensation. All 32 bits are simply reversed, end-to-end. So, just doing a REV will place the LSB into the MSB with all the bits reversed.
It wouldn't be much to add some extra configuration bits to the serial modes, but there's always going to be some software needed to handle either shifting or reversing. If anything, I could see making everything LSB first, and letting software handle the reversal for synchronous serial. That would cut 32 mux's out of the serial mode.
ADDED: And, it would be less hardware than 32 mux's times 64 pins. I think I'm going to do this. This only takes an hour, or so.
This should also work in ASYNC mode ? - as the Data itself is Async formatted (which your code above adds to SYNC)
Async mode does require the step of correct edge alignment, and I'm not sure of the best way to manage that in P2.
I think it could be done once, at config, but how does the user know they have the correct phase ?
Can the adjacent FCLK pin 'tap-into' the TX Pin's Baud Divider, using the adjacent pin feed feature ? That would simplify setup, (just one Baud set) & ensure edge lock.
You also say
The smallest transition clocks value I could use was 2 clocks. (20Mhz clock).
Another limiting factor is the sync. transmitter takes 2 clocks to shift the data out after an edge which is probably why 40Mhz can't be achieved.
Does that mean SPI or Async cannot do SysCLK/2, only SysC:L/4 ?
For your 20MHz speeds, working back to bits
20M/(384k/262m) = 13.64583
ie Sounding like a mix of 13 & 14 bit framing.
That's actually not too bad, as the Fast Serial is longer than classic UART, I recall 13 or 14 from my tests a while ago now,
If 40MHz was achievable, would this get to 30Mbd equiv ?
I also made all shifting I/O right-shift, or LSB-first. This had a nice effect on reducing the smart pin size.
Now, it's back to getting the USB wrapped up.
Sounds worthwhile.
Does that mean byte-streaming at SysCLK/2 Async can be done, with 10 spare clocks now (was just 2). ( taking std Async as 10 bit times, or 20 SysCLK at /2 )
Smaller is always good to see..
I'm not sure, but loops will be faster now.
How far away is an A9 intermediate image be with these new serial changes?
I already posted one intermediate release, but I will do another within an hour. This next one will always shift LSB-first and it's faster on the PINSETx instructions.
PINSETx instructions are now 10 clocks, down from 18.
All serial modes are LSB-first.
Doc's have been updated to reflect changes.