OPENCORES.ORG

Hi Damjan,

Hi Mike,
I have tested MAC with code in instruction cache, where the fetch delay is 
minimal. Anyway I'll have a look.

Can you just confirm that you use the latest version of the RTL?

regards,
Damjan

----- Original Message ----- 
From: "michael scott" <mike.scott@j...>
To: <openrisc@o...>
Sent: Thursday, July 21, 2005 11:59 AM
Subject: [openrisc] MAC Instructions

> Hi Damjan,
>          I forget to mention in my e-mail that I'm running the code
> from QMEM in order to get 16MegaMACs throughput at 16Mhz cpu clock
>
> Running code in WISHBONE memory (which in my case take 3 cycles)
> hides the problem as the multiplier pipeline always completes in time
>
> Interestingly, when executing l.div/l.ldivu in QMEM you can clearly
> see a stall for approx 32 cycles while the op completes
>
> I've attached some waveforms (zipped postcript)to show the effect
>
> If you look on the qm_rdata bus you can see the five mac instructions
> comprising altenating l.mac r2,r6 (0xc4023001) and  l.mac r2,r7 
> (0xc4023801)
> the corresponing MAc operation is observed on mult_mac_result
> and follows the sequence 32,96,128,192,224 as expected by the code (also
> attached)
> However, when executing l.macrc r4 the mac pipline has only reached the
> value 128 -there are still two cycles to go.
>
> just before time 2696 us on the waveforms it can be seen that this
> 'intermediate'
> value in copied to r4.
>
> I notice the line mac_stall_r is only high for 1 singe cycle. I belive it
> should
> high for a further two cycles for correct operation
>
> Hope this helps
>
> Regards
>
> Mike
>
>
>

--------------------------------------------------------------------------------

> _______________________________________________
> http://www.opencores.org/mailman/listinfo/openrisc 