AHHHHHHHHHHHH


we solved it! :D

Updates...this is crunch time!

Updates:

-from Erick: his counter is golden...(we'll see how golden it is when it has to talk to Andrew's crazy HW)
-from me: uart works for everything, but we're commenting that out for now...so Andrew can test his HW faster (hahaha...my computer can't take it anymoreeee)
-from Vlad: "no new code unfortunately.it's all in your (referring to everyone else) hands now"
-from Andrew: (bear w/ me...this is gonna be a long one)
Now for the update:
It doesn't work. But! :) We're now reading SRAM correctly, and we have a
debug register that gives us some insight into what is happening. It
actually took us most of the day to figure out if SRAM was broken and
then how to fix it, but we're sure it is fixed now, and that the
data_available signal is propagating through our system at the rate I
expect.

What remains to be fixed:

o Timing; particularly when the numberColumnRegisters see new data wrt
the cell counter. This will take until lunch tomorrow. But fixing this
will mean "it works."

o The 'done' signal needs to be fixed up to be a function of both the
cell counter and the data_available signal (Right now we announce done
when the cellcounter is 1111; but this doesn't give time to read the
16th cell from memory! This is why I tell Aliaa it only works for N=3
atm. It is a simple fix, but needs to wait until after timing is fixed.

o For performance, I want to send the 'clear' and 'go' bits at the same
time to reduce overhead. This basically means throwing the go signal in
a pipe. Trivial.

o The checksum_routines need to be amended so that setting 'N2' is only
done once. Trivial.

o Once all that is done and one possibility row is working fast (--side note by Aliaa: WHAT! FAST! what a concept!), we'll
put in Erick's awesome counter to get the other modes. Probably not too
bad.

o I think it is doable to do all that Monday. Tuesday I can try to add a
controller so we can just be called once per method, rather than once
for every row/column/block.

----he couldn't log in for some reason and requested to have this update posted. ----

dinner time...all day in lab again tomorrow.

Good extension or bad extension???

we're slowly inching towards hw-sw integration....and i have yet to figure out how uart really works. might try what happens with the hyperterminal....tomorrow!

As for the guys, Vlad is working on something...maybe his part of the report? Meanwhile...Andrew is working on loads of HW stuff. Erick has been compiling stuff for me! yayy :) he's yet to mess around with the given c-code & verilog, though, to see if the addressing all works out.

ttl: how long?? that extension was a double-edged sword...(Who wants to be in kemper the day we have our ceremony??)

Our Runtimes

we have started a scoreboard on the whiteboard in class...mainly, it's Infinite Execution vs BNSS vs us, and we welcome (i guess?) all the other teams too (your names are all up on there at least for the next 2 hours!).

Here are our runtimes:

Puzzle Runtime
3_1 11.31854 milliseconds
3_2 12.76578 milliseconds
4_1 0.90984202 seconds
4_2 8.55818944 seconds
5_1 2.198 seconds
5_2 FAIL (SLOW)
6_1 FAIL (SLOW)
6_2 2.25446164 seconds
7_1 9.26728258 seconds
7_2 FAIL (SLOW)
8_1 FAIL (puzzle is MESSED UP)
8_2 1.57 seconds
9_1 FAIL (SLOW)
9_2 12.3104381 seconds
10_1 ~4 minutes
10_2 26.23 second

For most updated times, click here

Long march to Friday's Demo

Over the weekend I finished most of the hardware accelerator logic, (Erick is doing the rest), and Vlad modified the software to use bit vectors rather than an array. Now it is time to figure out the details of interfacing with memory. We can use the CRC checksum accelerator as an example.. but it has more features than we need. For instance, it would be okay for the CPU to stall while waiting for the accelerator, rather than doing other work while waiting for an interrupt. Supporting these additional features will make the design more complicated; on the otherhand, trying to make something from scratch will almost certainly take longer to figure out.

Aliaa is working on the serial interface and trying to run the current software on the NIOS w/ SRAM. Vlad is improving his bit vector code to remove division where possible.

I'm not sure that we will really make the Friday deadline for full integration; but Sunday would be doable.

hard puzzles:
5_2
6_1
7_2
9_1
10_1

dunno what's wrong with 8_1. NOTE: there was a missing comma in 6_1, but I fixed that. hopefully the t.a remembers...line 31, the comma between 0 & 11 for puzzle 6_1 (this wasn't fixed even in the latest version of puzzles).

all other puzzles were solved pretty quickly on linux :) now to figure out that RS232 cable...

haven't figured out interfacing SRAM with checksum accelerator...pipelining reads is a little tricky, i guess. :p

We're making progress! YAY! :)

but some of those puzzles are hard (or incorrect)....boo.