calld myret,##hub ' <-- Error - Expected a constant,unary operator or "("
Crossing from cog to hub using a 9-bit relative jump augmented to 20 bits is a brain bender. I'll need to think about this. Sorry this issue has carried on so long.
calld myret,##hub ' <-- Error - Expected a constant,unary operator or "("
Crossing from cog to hub using a 9-bit relative jump augmented to 20 bits is a brain bender. I'll need to think about this. Sorry this issue has carried on so long.
It works Ok using the D reg variant so maybe a note in the documentation saying DONT AUGment the #rel9 variant and your done.
Actually the ##rel9 issue is not isolated to just CALLD.
Most of the looping and Jump-Bit variants, you would expect to be short & relative jumps, as they are on other MCUs.
It's just the CALL variants, where usually there is a far/long version in the tools ?
CALLD is more complicated than DJNZ because there are two different instructions for it. One is like DJNZ and the other has a 20-bit immediate field, plus absolute/relative bit.
Another thing about all the DJNZ-like instructions with immediate relative addressing, those addresses step 4x in hub exec, making them only branchable to commonly-aligned addresses. Same rule using AUGS with them.
I changed the DE2-115 compile to 4 cogs and 38 smart pins (63, 62, 35..0). It's at 97% capacity now. I need to make these AUGS+RDxxxx/WRxxxx changes and then I'll do a final compile on everything.
I changed the DE2-115 compile to 4 cogs and 38 smart pins (63, 62, 35..0). It's at 97% capacity now. I need to make these AUGS+RDxxxx/WRxxxx changes and then I'll do a final compile on everything.
Wow, that's quite a jump in smartpins.
Hmm, so a 8 cog "A9" would have all 64 smartpins then?
Could be a useful additional build for testing.
It's not as many as I was hoping for. That's eight Smartpins is as big as one Cog. They're bulker than I imagined.
I found that also interesting, but imagining what they do it makes some sense. Just naming them Smartpins took away the feeling that they are independent sub-processors running parallel to the 16 COGS.
I wonder what a really fast reduced instruction set P1 Cog with 512B (128 registers) would be in size and what it could perform instead of a Smart Pin ???
IOW a tailored software cog specifically for each I/O.
I wonder what a really fast reduced instruction set P1 Cog with 512B (128 registers) would be in size and what it could perform instead of a Smart Pin ???
IOW a tailored software cog specifically for each I/O.
What's unique about those smart pins is that they can input, output, and respond on a clock-by-clock basis.
I wonder what a really fast reduced instruction set P1 Cog with 512B (128 registers) would be in size and what it could perform instead of a Smart Pin ???
IOW a tailored software cog specifically for each I/O.
What's unique about those smart pins is that they can input, output, and respond on a clock-by-clock basis.
A specialised cog might be able to run at 2x the speed of the P2 cog.
Add a serialiser/deserialiser plus the counters with extra modes.
Add some basic software instructions.
Might be smaller than current, and perhaps more flexible too.
Perhaps 1 per P2 cog and connect as OR onto the existing I/O ring.
Anyway, it's too late for this. But it's nice to think about just the same.
I wonder what a really fast reduced instruction set P1 Cog with 512B (128 registers) would be in size and what it could perform instead of a Smart Pin ???
IOW a tailored software cog specifically for each I/O.
What's unique about those smart pins is that they can input, output, and respond on a clock-by-clock basis.
A specialised cog might be able to run at 2x the speed of the P2 cog.
Add a serialiser/deserialiser plus the counters with extra modes.
Add some basic software instructions.
Might be smaller than current, and perhaps more flexible too.
Perhaps 1 per P2 cog and connect as OR onto the existing I/O ring.
Anyway, it's too late for this. But it's nice to think about just the same.
Yes, nice idea, and worth thinking about, but lets save it until the P2 is done.
No! ... no ... NO! ... Won't be faster nor smaller. "Add a serialiser/deserialiser plus the counters with extra modes." - That's basically a smartpin right there.
I may have been surprised at their size but I'm happy with how they are and the flexibility they offer. Smartpins was one area that Chip extended when the extra die space came up. And, as he mentioned above, once you add in the die space needs of CogRAM/LUTRAM (4kB of dual ported SRAM per Cog) - which is not accounted for on the FPGA image compiles - it'll rebalance the proportions better.
SRAM is bulky! Dual ported is really bad for some reason. It put CogRAM alone at nearly 70% of the Cog's 424322 um² die area. That was back when LUTRAM was still single ported. LUTRAM is now the same size as CogRAM. 292 x 2 = 584 + 45ish = 630000 um² for a current Cog.
About 45000 is the logic and flops. Which is a mere 7.1% of the Cog's die space.
So, I'm guessing around 6000 um², or 1% of a Cog, will fit a Smartpin.
No! ... no ... NO! ... Won't be faster nor smaller. "Add a serialiser/deserialiser plus the counters with extra modes." - That's basically a smartpin right there.
Getting ideas and approaches from a group of knowledgeable people is always a good idea. Technology changes rapidly so it pays to take a look around when starting any new project. Keeps it from being limited by the preconceptions and limited knowledge of what is currently possible.
Comments
Crossing from cog to hub using a 9-bit relative jump augmented to 20 bits is a brain bender. I'll need to think about this. Sorry this issue has carried on so long.
It's just the CALL variants, where usually there is a far/long version in the tools ?
Any chance when you compile V18 for DE2-115 of dropping a cog(s) to get some smartpins back.
This also brings back DAC3(red).
Another thing about all the DJNZ-like instructions with immediate relative addressing, those addresses step 4x in hub exec, making them only branchable to commonly-aligned addresses. Same rule using AUGS with them.
The next step down from 8 cogs is 4 cogs.
I'm not sure what you mean about DAC3. Is pin 3 currently not a smart pin? I'm only on my phone at the moment.
As soon as compilation finishes for the BeMicro-A9 board, we'll find out.
DE2-115 has only 5 smartpins. 63,62,2..0
Hmm, so a 8 cog "A9" would have all 64 smartpins then?
Could be a useful additional build for testing.
Logic wise, but they don't have RAMs.
I found that also interesting, but imagining what they do it makes some sense. Just naming them Smartpins took away the feeling that they are independent sub-processors running parallel to the 16 COGS.
Interesting times are coming.
Mike
I wonder what a really fast reduced instruction set P1 Cog with 512B (128 registers) would be in size and what it could perform instead of a Smart Pin ???
IOW a tailored software cog specifically for each I/O.
What's unique about those smart pins is that they can input, output, and respond on a clock-by-clock basis.
Add a serialiser/deserialiser plus the counters with extra modes.
Add some basic software instructions.
Might be smaller than current, and perhaps more flexible too.
Perhaps 1 per P2 cog and connect as OR onto the existing I/O ring.
Anyway, it's too late for this. But it's nice to think about just the same.
Yes, nice idea, and worth thinking about, but lets save it until the P2 is done.
SRAM is bulky! Dual ported is really bad for some reason. It put CogRAM alone at nearly 70% of the Cog's 424322 um² die area. That was back when LUTRAM was still single ported. LUTRAM is now the same size as CogRAM. 292 x 2 = 584 + 45ish = 630000 um² for a current Cog.
About 45000 is the logic and flops. Which is a mere 7.1% of the Cog's die space.
So, I'm guessing around 6000 um², or 1% of a Cog, will fit a Smartpin.
Getting ideas and approaches from a group of knowledgeable people is always a good idea. Technology changes rapidly so it pays to take a look around when starting any new project. Keeps it from being limited by the preconceptions and limited knowledge of what is currently possible.
In part a thank you, but also a caution. With rapid changes in technology an impractical idea today may be a great one tomorrow.