Anyone know what happened to the setcz instruction?
I found modcz but I don't understand the required operands.
This is how I use it:
modcz 0,0 wc ' clear C for some operations that use this to determine behaviour
The 0,0 are the states for C and Z while wz wc specify which ones to set. So therefore, to set the carry:
modcz 1,0 wc ' Set C
MODCZ c,z {WC/WZ/WCZ} Modify C and Z according to cccc and zzzz. C = cccc[{C,Z}], Z = zzzz[{C,Z}].
'0' does happen to clear, but %1111 is needed to set. These MODCZ values that Ozpropdev listed are what work. Everything is a function of current flag states, except set and clear (%1111 and %0000).
OnSemi was running into delays from long routes associated with the DIR and OUT signals coming from the cogs and going to the smart pins. I added an extra layer of flops to cut the routing distance down. This will speed things up.
This means that the DIR and OUT signals from the cogs will take one more clock to get to the I/O pins, which nobody will like. To get the speed up to where it could otherwise be, this was necessary.
I'm compiling new FPGA images now, first for the BeMicro-A9 board. I'll have it posted in several hours. Then, I'll compile the Prop123-A9 board image.
If you guys could check these out (after I post them) and see that your code still runs, that would be good. It all seems to work on my end.
I wonder if OUT routing is the primary cause of the I/O timing issue in the FPGA. I'll be running my Smartpin based I/O response measuring program for sure.
This means that the DIR and OUT signals from the cogs will take one more clock to get to the I/O pins, which nobody will like. To get the speed up to where it could otherwise be, this was necessary.
Extra delays are never nice, but fixed known delays are far better than SysCLK dependent delays, and having any situation where delays are right on some cusp.
Does this extra delay affect any part of the smart pin operation ?
I guess it affects SW trigger, but not any of the pin-related signals ? ( ie Counting, Serial, Streamer all have the same top speeds ? )
I wonder if OUT routing is the primary cause of the I/O timing issue in the FPGA. I'll be running my Smartpin based I/O response measuring program for sure.
It was. I had jiggered things around to make them faster on the ASIC without adding another flop stage, but now we're back to what is better on the FPGA, too.
The FPGA pretty well tracks ASIC timing, but the ASIC is much finer grain and more can be done by the ASIC tools to tighten timing on critical paths than can be done by the FPGA tools.
This means that the DIR and OUT signals from the cogs will take one more clock to get to the I/O pins, which nobody will like. To get the speed up to where it could otherwise be, this was necessary.
Extra delays are never nice, but fixed known delays are far better than SysCLK dependent delays, and having any situation where delays are right on some cusp.
Does this extra delay affect any part of the smart pin operation ?
I guess it affects SW trigger, but not any of the pin-related signals ? ( ie Counting, Serial, Streamer all have the same top speeds ? )
The smart pins are unaffected by this. It's just the DIR and OUT signals coming from the cogs that are now delayed by another clock cycle.
Could you guys please try these out for a sanity check? The only difference should be that the OUT and DIR signals emanating from the cogs are delayed by one more clock cycle. This may have implications to your software. Signals will take one more clock to get from the cogs to the pins, which also means that they will echo back one clock later, as well. The pin-to-IN timing is the same. Just the DIR/OUT-to-pin timing has increased by one clock.
Could you guys please try these out for a sanity check? The only difference should be that the OUT and DIR signals emanating from the cogs are delayed by one more clock cycle. This may have implications to your software. Signals will take one more clock to get from the cogs to the pins, which also means that they will echo back one clock later, as well. The pin-to-IN timing is the same. Just the DIR/OUT-to-pin timing has increased by one clock.
Thanks.
For some reason I get an error when I try to download this zip file.
Could you guys please try these out for a sanity check? The only difference should be that the OUT and DIR signals emanating from the cogs are delayed by one more clock cycle. This may have implications to your software. Signals will take one more clock to get from the cogs to the pins, which also means that they will echo back one clock later, as well. The pin-to-IN timing is the same. Just the DIR/OUT-to-pin timing has increased by one clock.
Thanks.
For some reason I get an error when I try to download this zip file.
Could you guys please try these out for a sanity check? The only difference should be that the OUT and DIR signals emanating from the cogs are delayed by one more clock cycle. This may have implications to your software. Signals will take one more clock to get from the cogs to the pins, which also means that they will echo back one clock later, as well. The pin-to-IN timing is the same. Just the DIR/OUT-to-pin timing has increased by one clock.
Thanks.
For some reason I get an error when I try to download this zip file.
Hmm, not consistent yet on the OUT to IN times. Here's the usual 80 MHz results:
And, as expected, the ideal 20 MHz results:
Has v32c improved over v32b ? ie less jitter or less range of values ?
Are there other valid test frequencies between 20MHz and 80MHz you can try ?
V32c should have pushed up the point where the variations start to show ?
Exactly the same range of 1 to 2 clocks. Not identical pin pattern to historical v31 tests though. 40 MHz is the same as 20 MHz - no change there.
I guess the pins delays always 'wobble around' a little with each P&R, and maybe P&R does not place the registers as carefully, delay-wise, as the OnSemi scripts do.... ?
While technically not a bug, these are the results of some testing I did with the ALTS instruction.
I was kind of hoping that ALTS allowed me to use a full address for the base address so that I could feed it into a following RDxxxx/WRxxxx instruction.
addr- 0 1 2 3 4 5 6 7 8 9 A B C D E F
-----------------------------------------------------
080- 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F initial values for all tests below
084- 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-----x----- -----y----- -----z----- -----a-----
-----------------------------------------------------
mov y, ##$00000144
alts y, ##$11223344
mov a, #0
084- 00 00 00 00 5D 00 00 00 00 00 00 00 88 32 22 11
^^ ^^
-----------------------------------------------------
mov y, ##$00000144
alts y, ##$11223344
mov a, 0
084- 00 00 00 00 5D 00 00 00 00 00 00 00 3D 3D 3D 3D
^^ ???????????
-----------------------------------------------------
mov y, ##$00000014
alts y, ##$11223344
mov a, #0
084- 00 00 00 00 2D FF FF FF 00 00 00 00 58 33 22 11
^^ ^^ ^^ ^^
-----------------------------------------------------
mov y, ##$00000002
alts y, ##$00000080
mov a, #0
084- 00 00 00 00 02 00 00 00 00 00 00 00 82 00 00 00
-----------------------------------------------------
mov y, ##$00000002
alts y, ##$00000080
mov a, 0
084- 00 00 00 00 02 00 00 00 00 00 00 00 48 49 4A 4B
-----------------------------------------------------
mov y, ##$00000144
alts y, ##$00000144
mov a, #0
084- 00 00 00 00 44 01 00 00 00 00 00 00 88 00 00 00
^^ ^^ ^^
-----------------------------------------------------
mov y, ##$00000014
alts y, ##$00000144
mov a, #0
084- 00 00 00 00 14 00 00 00 00 00 00 00 58 01 00 00
-----------------------------------------------------
mov y, ##$00000014
alts y, ##$00000344
mov a, #0
084- 00 00 00 00 15 00 00 00 00 00 00 00 58 03 00 00
^^
-----------------------------------------------------
From these results, I deduced a few things that I think are correct...
1. The ALTS instruction writes a result back into its' D register.
2. The ALTS D register must be =< $1F (5bits max) or D is overwritten with an incorrect value
3. The ALTS S register must be =< $1FF (9 bits max) or D is overwritten with an incorrect value
4. If the ALTS D register is > $1FF then the S value passed to the following instruction is incorrect
5. If the ALTS D register is =< $1F and the S value is > $1FF then while D is overwritten, the correct value of S is passed to the following instruction
Comments
Can you use RCZR D or maybe a SKIP D instead?
'0' does happen to clear, but %1111 is needed to set. These MODCZ values that Ozpropdev listed are what work. Everything is a function of current flag states, except set and clear (%1111 and %0000).
This means that the DIR and OUT signals from the cogs will take one more clock to get to the I/O pins, which nobody will like. To get the speed up to where it could otherwise be, this was necessary.
I'm compiling new FPGA images now, first for the BeMicro-A9 board. I'll have it posted in several hours. Then, I'll compile the Prop123-A9 board image.
If you guys could check these out (after I post them) and see that your code still runs, that would be good. It all seems to work on my end.
Thanks.
Does this extra delay affect any part of the smart pin operation ?
I guess it affects SW trigger, but not any of the pin-related signals ? ( ie Counting, Serial, Streamer all have the same top speeds ? )
It was. I had jiggered things around to make them faster on the ASIC without adding another flop stage, but now we're back to what is better on the FPGA, too.
The FPGA pretty well tracks ASIC timing, but the ASIC is much finer grain and more can be done by the ASIC tools to tighten timing on critical paths than can be done by the FPGA tools.
The smart pins are unaffected by this. It's just the DIR and OUT signals coming from the cogs that are now delayed by another clock cycle.
https://drive.google.com/file/d/10nhZYSZ3wGYi2JiVmayUFNyGzWhsrpn_/view?usp=sharing
Could you guys please try these out for a sanity check? The only difference should be that the OUT and DIR signals emanating from the cogs are delayed by one more clock cycle. This may have implications to your software. Signals will take one more clock to get from the cogs to the pins, which also means that they will echo back one clock later, as well. The pin-to-IN timing is the same. Just the DIR/OUT-to-pin timing has increased by one clock.
Thanks.
Just need a RBF format file for the P123_A9 as evanh pointed out.
WHOOPS!!!!!
Change that Prop123-A9 .jic to .rbf. When copying the file, I put the wrong extension on it.
P123-A9 V32c flashed Ok.
I've run everything I have here and it all seems to be running Ok.
Chip, BTW back home for the day now.
Direct link to the zip file:
https://drive.google.com/uc?export=download&id=1zjwzv1ZsdinWMBBOsTm3pEXf-4p8i9jf
Edit: Downloaded fine under Windows. Not sure what went wrong on the Mac. I even tried Chrome as well as Safari.
https://drive.google.com/file/d/10nhZYSZ3wGYi2JiVmayUFNyGzWhsrpn_/view?usp=sharing
And, as expected, the ideal 20 MHz results:
Are there other valid test frequencies between 20MHz and 80MHz you can try ?
V32c should have pushed up the point where the variations start to show ?
With repeated runs of the same there is also some unstable jitter effects on some pins as well. No surprise really.
Could you please point me to the post where I can find the routine you've been using, to measure the pin-to-pin timings you've been commenting about?
Sorry, but I'm having a hard time, trying to find it among that many posts this thread now has.
Thanks in advance.
Henrique
https://forums.parallax.com/discussion/comment/1430342/#Comment_1430342
Here's my current source also:
While technically not a bug, these are the results of some testing I did with the ALTS instruction.
I was kind of hoping that ALTS allowed me to use a full address for the base address so that I could feed it into a following RDxxxx/WRxxxx instruction.
addr- 0 1 2 3 4 5 6 7 8 9 A B C D E F ----------------------------------------------------- 080- 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F initial values for all tests below 084- 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -----x----- -----y----- -----z----- -----a----- ----------------------------------------------------- mov y, ##$00000144 alts y, ##$11223344 mov a, #0 084- 00 00 00 00 5D 00 00 00 00 00 00 00 88 32 22 11 ^^ ^^ ----------------------------------------------------- mov y, ##$00000144 alts y, ##$11223344 mov a, 0 084- 00 00 00 00 5D 00 00 00 00 00 00 00 3D 3D 3D 3D ^^ ??????????? ----------------------------------------------------- mov y, ##$00000014 alts y, ##$11223344 mov a, #0 084- 00 00 00 00 2D FF FF FF 00 00 00 00 58 33 22 11 ^^ ^^ ^^ ^^ ----------------------------------------------------- mov y, ##$00000002 alts y, ##$00000080 mov a, #0 084- 00 00 00 00 02 00 00 00 00 00 00 00 82 00 00 00 ----------------------------------------------------- mov y, ##$00000002 alts y, ##$00000080 mov a, 0 084- 00 00 00 00 02 00 00 00 00 00 00 00 48 49 4A 4B ----------------------------------------------------- mov y, ##$00000144 alts y, ##$00000144 mov a, #0 084- 00 00 00 00 44 01 00 00 00 00 00 00 88 00 00 00 ^^ ^^ ^^ ----------------------------------------------------- mov y, ##$00000014 alts y, ##$00000144 mov a, #0 084- 00 00 00 00 14 00 00 00 00 00 00 00 58 01 00 00 ----------------------------------------------------- mov y, ##$00000014 alts y, ##$00000344 mov a, #0 084- 00 00 00 00 15 00 00 00 00 00 00 00 58 03 00 00 ^^ -----------------------------------------------------From these results, I deduced a few things that I think are correct...1. The ALTS instruction writes a result back into its' D register.
2. The ALTS D register must be =< $1F (5bits max) or D is overwritten with an incorrect value
3. The ALTS S register must be =< $1FF (9 bits max) or D is overwritten with an incorrect value
4. If the ALTS D register is > $1FF then the S value passed to the following instruction is incorrect
5. If the ALTS D register is =< $1F and the S value is > $1FF then while D is overwritten, the correct value of S is passed to the following instruction
See "Register Indirection" in the V32 P2 Documentation in the first post.