potatohead wrote: »
We have interrupts for that now.
cgracey wrote: »
Over the last several days, I've been consolidating all instruction decoding to the cycle before the two cycles that the instructions actually execute in.
This has two advantages:
1) It actually saves logic, since replica logic doesn't exist at two different pipeline stages.
2) It makes things go faster.
Prop2-Hot worked this way, but I had abandoned this in the new design, since it requires a flipflop per decode. I guess the new design drifted to the point where there were few enough decodes that flops became more efficient than extra logic.
This change caused Fmax, for the 8-cog/64-smartpin Cyclone V A9 boards to go from 84.0 MHz to 89.6 MHz. That's a 6.7% speed increase that should translate straight into the silicon Fmax.
And look at the slack histogram on the FPGA. There are just a few dangling paths that are keeping the FPGA from reaching 100 MHz. The ASIC tools will be able to tuck these in a lot tighter.
I will be getting a v28 out soon and update the documentation accordingly.
One other thing... I changed the memory mapping slightly so that the last 16KB of hub RAM always appears at both it's natural location and at $FC000..$FFFFF. The write-protect mechanism works at both of the last 16KB address ranges. The debug interrupt jumps are always only accessible at the end of the 1MB map, though, and they are subject to the write-protect mechanism. This will let people use the memory more naturally if they are not caring about fixed code at the top of the 1MB hub memory map.
msrobots wrote: »
I still do not get the importance of treating the debug vectors different from the rest of the ROM.
Why are the debug vectors not accessible at the end of 512KB and why they are excluded from being loaded at boot time?
Rayman wrote: »
I must have forgotten how to use LOC...
Have some code that was working fine with this
But then, I removed some debugging code and it stopped working...
Replaced with this
and it works again...
The label, OV965X_REGS_QVGA, is around $400 in HUB
Rayman wrote: »
Is there a reason that loc can't work with #@ below $400?
A symbol declared under ORGH will return its hub address when referenced.
A symbol declared under ORG will return its cog address when referenced,
but can return its hub address, instead, if preceded by '@':
For immediate-branch and LOC address operands, "#" is used before the
address. In cases where there is an option between absolute and relative
addressing, the assembler will choose absolute addressing when the branch
crosses between cog and hub domains, or relative addressing when the
branch stays in the same domain. Absolute addressing can be forced by
following "#" with "\".
but can return its hub address, instead, if preceded by '@'
Cluso99 wrote: »
They cannot be used for hubexec code, only for rd/wr instructions. ie data or cog/lut code that can be loaded into cog/lut for execution.
jmg wrote: »
IIRC the P2 PLL/VCO is now like most, with a SysCLK divider, and a VCO_FB_Divider, and Xtal_FB_Divider to the common PFD frequency.
Command then looks something like
">Prop_PLL Sys_Div VCO_Div Xtal_Div" + some pause for PLL lock, and host Baud-redefine, and then '>' at the new higher Baud rate.
Addit: Using this, a simple means to boost boot from a fast-UART part like EFM8UB3 becomes available
With the available ~ 32kBytes of P2 code storage in the UB3, that's 5.4~4ms loading times, at 6~8MBaud that part should be capable of.
(plus other hard-wired delays inside P2, hopefully, those are not too great...)
clkset #$FF 'switch to 80MHz (if pll, else 50MHz)
nop ' seems to need delay after clkset (otherwise next coginit ids incorrectly)
coginit #0,#@RESET ' RESET does a COGID so that #0 can run the console instead of an IDLE loop
go cogid x
lp drvnot x
x res 1
Cluso99 wrote: »
Are you still using v26, and might that be different to v27a/z/zz ?
I have my SD card booter ready for v28. Just need to know where the SD pins will be.