Extending the precision of Woodstock or Saturn based calculators

09282017, 12:40 PM
(This post was last modified: 09282017 12:42 PM by Alejandro Paz(Germany).)
Post: #17




RE: Extending the precision of Woodstock or Saturn based calculators
I have updated the Parallel Saturn core. At this point many instructions have been implemented. Some instructions are still missing like the ones dealing with device configuration, shutdown, interrupts. Memory read is partially implemented and memory write is still missing. But there is enough to let the synthesizer give us an idea of how big and fast it is. Big and slow for a MachXO27000ZE1
Code:
90 % of this FLGA is pretty big, and the maximum speed is well, slow. There are a couple of important points to consider: The 64bit computations, ADD, SUB, Logic and a mux are performed between two consecutive flanks of the clock. I haven't attempted any optimization here beyond latching both source arguments (Line 241..248, saturn_alru.v). The slowest path goes through the subtract unit, as expected. But clock speed doesn't tell the whole story, if we do not know how many clocks are needed for an opcode. Small opcodes like P=n take 4 clocks to complete but fetch can take up to 3 clocks. While the perfetcher does a pretty good work it can be greatly improved. Jumps take 2 clocks plus fetch. An unaligned opcode needs at least 2 extra clocks for fetch. For comparison, the nibble serial implementation on the same FPGA can achieve 16 MHz. But opcodes need many more cycles: Code:
27 cycles @ 16 Mhz = 1.68 us 7 cycles @ 3.2 Mhz = 2.18 us 9 cycles @ 16 Mhz = 0.5625 us 5 cycles @ 3.2 Mhz = 2.18 us [/code] I think that without improving the prefetcher it will be difficult to see any gain . Fetch and subsequent execute and streamlining of the fetch state machine. At least one clock can be dropped as ST_INIT is not really needed, imho. The ALU path can also be extended to two cycles allowing to double the frequency. 

« Next Oldest  Next Newest »

User(s) browsing this thread: 1 Guest(s)