| lkcl | mePy2[m]: what we're doing is... well... "slightly cheating". we're pretty much blind-copy-paste using microwatt, translating it to nmigen :) | 12:15 |
|---|---|---|
| lkcl | the difference is that we will be using out-of-order "precise exceptions" rather than "stalls" as shown in that article | 12:16 |
| lkcl | (this comes later btw) | 12:16 |
| lkcl | the way that precise exceptions work, you have to first understand and appreciate the "obvious" fact that once you've written a result to memory or to a regfile, it's not like you can "undo" that | 12:17 |
| lkcl | although some out-of-order systems do actually do that! they have a "rollback" mechanism where they take regular snapshots of the entire state (!!) | 12:18 |
| lkcl | the way that the 6600 "precise" system works is: anything that can cause "damage" is held off by a simple flag called a "shadow" bit. | 12:19 |
| lkcl | this does nothing more complex than stop the pipeline from writing (to memory or regfile) | 12:19 |
| lkcl | so the result just sits there waiting in an output buffer. | 12:19 |
| lkcl | the important bit is: everything AFTER that "held" instruction is ALSO "shadowed" (hence the term "shadow") | 12:20 |
| lkcl | the problem with exceptions is: you get half-way through calculating the result, and other instructions were issued after it (also not yet completed) and you find "argh actually we can't complete this, must throw an exception" | 12:21 |
| lkcl | all you do is: | 12:21 |
| lkcl | pull the "go die" flag on all the "shadowed" instructions, they IMMEDIATELY stop (die), and in that very same cycle you can push the "exception" into the instruction queue just like it says in that article | 12:23 |
| lkcl | but | 12:23 |
| lkcl | not "wait for some stalling to occur to flush out the pipeline" | 12:23 |
| lkcl | execute RIGHT NOW the exception, because all the downstream (incomplete, shadowed) instructions were IMMEDIATELY pulled from all pipelines. | 12:24 |
| lkcl | mePy2[m], https://git.libre-soc.org/?p=soc.git;a=commitdiff;h=3df06e5cc2009b5918db8eee43785d1fc1f15866 | 16:08 |
| lkcl | note the comment | 16:08 |
| DaKnig | whats the status of the project? how close are you to printing the ASIC? | 16:09 |
| lkcl | busy! :) we're under a conditional code-freeze ("if we can get L1 caches working they go in") | 16:09 |
| lkcl | because it's a compelling use-case / test-case for Staf, for him to test the libre-licensed SRAM memory cell he's creating | 16:10 |
| lkcl | JTAG "boundary scan" for pinouts is done. that's with Staf's C4M JTAG library (very cool, well-written, well tested) | 16:11 |
| lkcl | s/pinouts/peripherals | 16:11 |
| lkcl | needs a unit test though | 16:11 |
| lkcl | we've a hard (fixed) deadline for the GDS-II file of Dec 2nd | 16:14 |
| lkcl | so i have to be quite strict about what goes in | 16:14 |
| lkcl | the final month (all of November, basically) will be nothingggg but testing of the coriolis2 layout | 16:14 |
| DaKnig | what's the GDS-II file? (sorry, totally unrelated) | 16:15 |
| lkcl | https://en.wikipedia.org/wiki/GDSII | 16:15 |
| lkcl | standard file-format for ASIC layout tools. | 16:15 |
| DaKnig | I see | 16:16 |
| lkcl | the size of files as they go through different processing is hilarious. it's literally an order of magnitude each time | 16:17 |
| lkcl | we start with 50,000 lines of HDL | 16:17 |
| lkcl | that becomes 10 megabytes of yosys ILANG | 16:17 |
| lkcl | which becomes 100 megabytes of coriolis2 .ap files | 16:17 |
| lkcl | which becomes a GIGABYTES of GDS-II file (!!) | 16:18 |
| lkcl | mmmmental :) | 16:18 |
| DaKnig | are they easily compressible though? | 16:18 |
| lkcl | yeah, they're pretty repetitive | 16:18 |
| lkcl | and text-based (ASCII) format | 16:19 |
| *** DaKnig <DaKnig!~pi@unaffiliated/daknig> has left #libre-soc | 17:29 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!