Libre RISC-V Mailing list Archives (accessible via public-inbox)
 help / color / Atom feed
From: bugzilla-daemon@libre-soc.org
To: libre-riscv-dev@lists.libre-riscv.org
Subject: [libre-riscv-dev] [Bug 318] fix LDSTCompUnit
Date: Sun, 17 May 2020 10:31:24 +0000
Message-ID: <bug-318-13-fvqr0cLO5R@https.bugs.libre-soc.org/> (raw)
In-Reply-To: <bug-318-13@https.bugs.libre-soc.org/>

https://bugs.libre-soc.org/show_bug.cgi?id=318

--- Comment #3 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
the "ultimate" success test of this is for experiment/score6600_multi.py
to not go permanently into "busy" mode.

the videos show how LDSTCompUnit is *supposed* to work... but doesn't
quite.

the issue on the current commit is that the address latching is not
occurring - not being transferred through correctly to mem_w_data -
for ST operations.

i *think* it is working fine on LD operations.

you can see in the gtkwave timing diagram that:

* cycle @ 50ns mem_w_en (and so mem_w_data) change
* however cycle @ 40ns *should* have set mem_w_addr to 0x6

this *actually* occurs 4 cycles later for the *second* ST operation!

if you then look at alu_o (further up), you can see it is:

* 0x0002 @ 20ns
* 0x0006 @ 30ns (the required, correct value)
* however ad__rel - the signal that says "address is valid"
  was *one cycle early*

(ad__rel in gtkwave is the name for the object ad.rel, and there is
a "convenience" variable in the python code ad_rel_o which points
to self.ad.rel)

it's nearly there.

notes:

* every req signal (rd.req[0], rd.req[1], rd.req[2], wr.req[0],
  wr.req[1], ad.req and st.req) has a corresponding "go" signal
  (rd.go[0] etc.)

  these are from the data structure created on-the-fly by
  "go_record"

* outgoing request ("req") signals may be held ASSERTed indefinitely until
  such time as their associated "go" signal is ASSERTed for one cycle

* on assertion of the corresponding "go" signal, the associated "req"
  signal **MUST** be de-asserted

this is basically wishbone etc. etc. etc. standard ready_o / valid_i
signalling conventions

in TestLDSTCompUnit, you can see the following line:

        m.d.comb += self.ad.go.eq(self.ad.rel) # link addr-go direct to rel

this is done deliberately because otherwise it becomes necessary to write
a split pair of co-routines in the unit test:

* one that watches ad.rel and sets ad.go for one cycle
* one that watches wr.rel[1] and sets wr.go[1] for one cycle

strictly speaking *all* {sig}.go signals could be made equal to all {sig}.rel
signals, combinatorially, and the code should function perfectly correctly.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

  parent reply index

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-17 10:08 [libre-riscv-dev] [Bug 318] New: " bugzilla-daemon
2020-05-17 10:09 ` [libre-riscv-dev] [Bug 318] " bugzilla-daemon
2020-05-17 10:10 ` bugzilla-daemon
2020-05-17 10:31 ` bugzilla-daemon [this message]
2020-05-17 10:35 ` bugzilla-daemon
2020-05-17 10:51 ` bugzilla-daemon
2020-05-17 11:02 ` bugzilla-daemon
2020-05-17 13:20 ` bugzilla-daemon
2020-05-17 14:44 ` bugzilla-daemon
2020-05-17 16:43 ` bugzilla-daemon
2020-05-17 17:06 ` bugzilla-daemon
2020-05-17 23:01 ` bugzilla-daemon
2020-05-17 23:31 ` bugzilla-daemon
2020-05-18  4:09 ` bugzilla-daemon
2020-05-18 16:26 ` bugzilla-daemon
2020-05-18 16:38 ` bugzilla-daemon
2020-05-18 16:56 ` bugzilla-daemon
2020-05-18 17:19 ` bugzilla-daemon
2020-05-20  3:09 ` bugzilla-daemon
2020-05-20  3:17 ` bugzilla-daemon
2020-05-20 14:40 ` bugzilla-daemon
2020-05-21 12:05 ` bugzilla-daemon
2020-05-21 12:58 ` bugzilla-daemon
2020-05-21 17:55 ` bugzilla-daemon
2020-05-25  0:14 ` bugzilla-daemon
2020-06-10 16:44 ` bugzilla-daemon
2020-06-10 17:20 ` bugzilla-daemon
2020-06-11 22:58 ` bugzilla-daemon
2020-06-11 23:22 ` bugzilla-daemon
2020-06-12 10:58 ` bugzilla-daemon
2020-06-12 11:13 ` bugzilla-daemon
2020-06-12 11:15 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-318-13-fvqr0cLO5R@https.bugs.libre-soc.org/ \
    --to=bugzilla-daemon@libre-soc.org \
    --cc=libre-riscv-dev@lists.libre-riscv.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Libre RISC-V Mailing list Archives (accessible via public-inbox)

Archives are clonable: git clone --mirror https://inbox.libre-soc.org/libre-riscv-dev

Example config snippet for mirrors


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git