f-cpu/qdcpoc2/README.txt
created Sat Aug  4 19:00:41 2001 by whygee@f-cpu.org
version Mon Aug 13 05:39:00 2001

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
This archive is NOT under GPL. See the distribution
terms in f-cpu/COPYING.txt. It is an ongoing work
and a lot of things change quickly ! The purpose
of this archive is to show the status of my work,
not to provide something that really works, so
don't be surprised by compiling errors or SIGSEGVs !
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

QDCPOC2 is a rewrite and reorganisation of QDCPOC.
Read the associated files in the qdcpoc directory
for all the rationale.

QDCPOC2 is even more closer to VHDL than QDCPOC was.
The clocking must be completely rewritten, for example.

Besides the clocking, some issues were raised and
QDCPOC, despite containing some "useful meat", was
flawed on some critical points. if you had started developping
on QDCPOC, now you know that you should not have.
You were warned anyway, and the copying restrictions still
apply for this bundle. I just want to save you some
hours during which you could have a life, for example.

ISSUES :

* bit ordering : it was rather easily fixed but not tested.

* buffers : i had put a FF gate at the output of the Writeback
Xbar MUX. This is plain wrong. I have used a global variable
then relied on it, but the memorisation should happen at
the output of the execution units.
The solution is to rewrite the "Xbar" as a whole, integral unit.
It was a good idea to split the Xbar but i have reached
its limits.

* Register set : i had thought that the register set
would have zero latency for write. This is wrong, and
i have to add a second bypass level to correct the situation.

* Power-up, reset and initialisation : i will include a BIST.
The file is created but no strategy is defined yet.

A complete rewrite is therefore necessary.

.


Tue Aug  7 03:51:57 2001 :

The coding strategy for QDCPOC was to start from the pipeline's
end (because of the particular "clocking" of the program).
It proved successful in removing some difficult points.

For this QDCPOC2, the starting point is the register set,
then the Xbar. Starting from the decoder gives too much problems
at once.

The register set has 2 parts : read/write and updating the
flags. At this point, i'm always closer to VHDL without ever
touching it. I would need synthesis tools to evaluate the
coding choices.

let's go forward anyway, and advance to the Xbar, because
QDCPOC(x) is meant to solve clocking/scheduling problems.

So i try to make "something working", based on the amount of
hack i have already done.

                   -----oO0Oo-----

Remark : In this code, you have remarked that i don't care
a fuck about "good C coding practices". If that can reassure
you, i have never cared anyway, and i have never had problems.
In the present case, i have declared all the "global variables"
in qdcpoc2.h, so they can communicate with each others.
However i have not included the "local global" variables
in this file : this would make the file heavy and unreadable,
and VHDL usually keeps its "local" variables inside the
body, so you can consider qdcpoc2.h as an "interface".
The point here is that C local variables are flushed once
the routine exited, but we need to memorise some of these
signals. So i have declared them close to where i use them.

                   -----oO0Oo-----


Another issue : the polarity of the R7_zero flags.
different files disagree. i'm still puzzled but here is
the basics :

the CMOVE and CJMP instruction "execute" by default,
this means that all the fields (condition, negation and register)
are cleared. In other words : the default condition is
"register 0 is equal to 0" which is always true.

However, i don't know if it's a good idea to represent a 0
(value of the register) by a 1 (boolean true). Another "good sense"
thing says that the R7_zero flag is determined by a big 0R
so the value is 0 if the register is 0.

There's a little problem here. i'll won't bother much anyway,
otherwise i'll never write anything.

Tue Aug  7 05:14:44 2001 :

UPDATE : concerning the R7_zero polarity, i choose the OR way :
it will be modified anyway during synthesis if needed, and it
is more friendly with the C idioms (global variables are initialised
to zero before the main() is called).

                   -----oO0Oo-----

Another issue : i wonder if the structure in register_set.c
that splits the register into 5 parts can be ported harmlessly
on big-endian machines. There should be no problem at the VHDL
level (because we can define each bit individually) but i remember
that at some points, the bit position is meaningful (flag update).

be ready for some bugs, particularly on MAC/SUN machines.

