IRC logs for #openrisc Monday, 2012-11-26

@stekernhmm, otherwise it's probably not so problematic, except when an exception happens when an bubble is in execute stage06:45
@stekernor actually, perhaps that's not a problem, the same pc should be in execute so it will return back to that insn07:06
@stekernah, but I need to prevent the execute pc to advance in to ctrl/mem stage when the bubble nop moves from execute->ctrl/mem09:11
@stekernok, think I've got it working now, at least all tests except uart and the debug except tests work as they should10:15
@stekernand the uart and debug except tests didn't work before neither10:15
@juliusbstekern: nice one!10:51
@juliusbyes, the hazards are annoying to handle, but have to be done10:51
@stekernthey are not only annoying, it's hard to not create slow paths when solving them10:54
@stekernbefore the nop bubble that hazard handling made it go ~30MHz, now it's back up to ~85MHz10:55
@stekernstill some other stuff that is making long paths, but it's getting closer10:56
@stekernone is an odd comb-loop with the ticktimer exception10:56
@stekern(I might well have accidently created that loop, so don't waste time thinking about that, not just yet at least ;))12:32
@stekernfound out what was wrong with the uart-simple test13:18
@stekernI had screwed up the flag tracking (the one that I so proudly said I had fixed some day ago)...13:18
@stekernI was looking at the flag_set and flag_clear signals and comparing them to the flag bit in sr13:19
@stekernbut the sr is not written until in memstage, so theres a 1-clock gap between flag_set and sr[FLAG] going high13:21
-!- derRicha1d is now known as derRichard16:49
@stekernthink I've killed the last slow path (with an extremely ugly hack), fmax landed on 78 MHz for cyclone IV and 82 MHz for spartan618:48
@stekernit's not extremely bloated neither, map report for spartan6 claims 1248 slices18:49
@stekernthe extremely ugly hack has to do with the condition where a lsu op is in mem stage stalling a branch in execute stage18:52
@stekerna lot of logic assumes that a branch can't be stalled (in particular the fetcher)18:53
@stekernso I tried holding off branch_occur with execute_valid (that's pretty ugly too), but that created a slow path on cyclone iv18:54
@stekernso I'm using the bubble logic to squeeze in a nop between lsu ops and branches18:54
@stekern... as a temporary solution, I might add ;)18:56
@stekernjuliusb: this is interesting, comparing to the numbers you have in your presentation for cappuccino: 3211 (1234), it looks like it's smaller now: 2773 (1198)19:13
@stekernwhat did you have in the system when you did those comparisons?19:13
@stekernand how did you get or1200 to get an fmax of 95 MHz?19:14
@stekernI mean, it never go over 50 MHz in orpsoc19:17
-!- Netsplit *.net <-> *.split quits: ams, derRichard22:01
@juliusbstekern: very nice work mate!23:01
@juliusbit's annoying to try to get the best performance out of the fetch stage when taking into account the possibility of stalls elsewhere :-/23:02
@juliusbstekern: I think I did just a top-level wrapper for the mor1kx and or1200 to get those numbers23:02
@juliusband gave it a 100MHz clock I think23:02
@juliusbto get those numbers23:03
-!- derRicha1d is now known as derRichard23:03

Generated by 2.15.2 by Marius Gedminas - find it at!