[CALU] Re: [CALU] Re: Wir können und sollten uns einen zyklus bei teuren alu ops sparen
- From: Benedikt Huber <benedikt@xxxxxxxxxxxxxxxxxx>
- To: calu-ss2010-tuwien@xxxxxxxxxxxxx
- Date: Sun, 23 May 2010 02:59:03 +0200
On 21.05.2010, at 10:21, Günther Wimpassinger wrote:
Zitat von Benedikt Huber <benedikt@xxxxxxxxxxxxxxxxxx>:
On 20.05.2010, at 19:09, Günther Wimpassinger wrote:
ALU_ADD,ALU_SUB,ALU_SLL stellt kein problem dar. Das zu
synthetisieren bring mir ein Design mit ca 90 MHz.
Hallo,
ich habe gerade einen eher erfolglosen (weil fmax reduzierenden)
Versuch hinter mir, die Logik fuer memory mapped IO in ein eigenes
Modul auszulagern.
Kannst du mal den Sourcce "herzeigen". Ich sehe im Moment keine
Veränderungen nach einem "git pull"
Hallo zusammen,
die Loesung fuer das fmax Problem war ein Quartus Upgrade ;) Ganz
durchschaue ich Quartus seine fmax-Logik aber trotzdem nicht...mit der
Web Edition war ich noch nie ueber 61Mhz.
Ich arbeite im remote branch 'iomapped'.
Zum Prozessor in iomapped:
a) Momentan nur mit Modelsim getestet (betrifft vorallem UART sim)
b) Es gibt ein mapped_io und ein counters Modul
c) Fuer letzteres is ein Stall Counter (stall2if), ein Flush
Counter(flush2id) und ein Cycle Counter implementiert
d) Ist r15 irgendwie speziell? die uartsendready funktion funktioniert
damit nicht im modelsim (siehe 9fcd153de92d2337e0b4cbcae2294efc26e244c4)
Nach dem Testen im Labor werd ich das ganze in den master mergen.
lg, benedikt
p.s.: Mit dem Prozessor in HEAD funktioniert modelsim nicht (sim/
pisp_template)
Other related posts:
