From: Staf Verhaegen <staf@fibraservi.eu>
To: libre-riscv-dev@lists.libre-riscv.org
Subject: Re: [libre-riscv-dev] Debug port (was Re: minimum viable ASIC)
Date: Wed, 20 May 2020 18:44:06 +0200
Message-ID: <803285a5aa4bed5be9c8d4bc5855f49174742f33.camel@fibraservi.eu> (raw)
In-Reply-To: <CAPweEDx5zV3K3y=gjpArhpZ5VrKYL01=938EYA4xd0PjROqppg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2338 bytes --]
Luke Kenneth Casson Leighton schreef op vr 08-05-2020 om 23:19 [+0100]:
> ---crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
> On Fri, May 8, 2020 at 6:23 PM Staf Verhaegen <staf@fibraservi.eu> wrote:
>
> ah. as a software engineer, the practice of using wildcard imports isan extremely bad one. i strongly advocate *not* getting into thehabit of doing "from nmigen import *" everywhere - it will make yourlife - and other users lives - absolute hell when it comes to tryingto track and debug code.
> minerva has a JTAG interface as well. i corrected the practice ofusing "import *" in this one
Would 'import nmigen as nm' work for you?I did not touch code for a few months and in the mean time I do use a more PEP compliant code style. But I am annoyed by the individual list of things to import. For nmigen or Hurricane there is typically a few lines of these includes. When I change for example a Pad to a Rectilinear I may have to update the import list. I don't see value add of this and it annoys me a lot.So I am thinking of switching to 'import Hurricane as hur' and 'import nmigen as nm'To me the only valid reason for not using wild cards is that a later wild card import may replace something you did import before; this is avoided by namespacing the import with 'import ... as ...'.
> it looks like the minerva team got a long way with that. alsoprovided a wishbone master interface:
> https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/minerva/units/debug/wbmaster.py;h=db02af95b4eb3ef8ac25b348f3abaa2bcbe7d96f;hb=a54adcb65bad37b398b11e33a824c7d08c5fe509
That code seems to focus on the debugging protocol over the JTAG interface the lower level part seems to be missing.In debug/top.py:...
# FIXME: figure out where JTAGTap is
# from jtagtap import JTAGTap
class JTAGTap:
def __init__(self):
raise NotImplementedError(
"jtagtap package not found: figure out where JTAGTap is")
...
My JTAG interface does actually the low level part, the protocol has to be done by the user on top of it. I do think I have a flexible way of adding extra shift registers and jtag commands. I also do provide boundary scan for the IO pins which should make PCB testing much easier (BTW, this was actually the original use case for JTAG).
greets,Staf.
[-- Attachment #2: Type: text/plain, Size: 177 bytes --]
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
next prev parent reply index
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-08 9:50 [libre-riscv-dev] minimum viable ASIC Luke Kenneth Casson Leighton
2020-05-08 10:29 ` Staf Verhaegen
2020-05-08 10:42 ` Luke Kenneth Casson Leighton
2020-05-08 11:10 ` Staf Verhaegen
2020-05-08 12:43 ` Yehowshua
2020-05-08 12:46 ` Luke Kenneth Casson Leighton
2020-05-08 19:08 ` Staf Verhaegen
2020-05-08 20:35 ` Luke Kenneth Casson Leighton
2020-05-08 12:49 ` Yehowshua
2020-05-08 12:50 ` Yehowshua
2020-05-08 12:59 ` Yehowshua
2020-05-08 12:59 ` Yehowshua
2020-05-08 14:59 ` Luke Kenneth Casson Leighton
2020-05-08 15:00 ` Yehowshua
2020-05-08 15:27 ` [libre-riscv-dev] Debug port (was Re: minimum viable ASIC) whygee
2020-05-08 16:55 ` Luke Kenneth Casson Leighton
2020-05-08 17:23 ` Staf Verhaegen
2020-05-08 22:19 ` Luke Kenneth Casson Leighton
2020-05-20 16:44 ` Staf Verhaegen [this message]
2020-05-20 17:22 ` Luke Kenneth Casson Leighton
2020-05-29 10:30 ` Luke Kenneth Casson Leighton
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=803285a5aa4bed5be9c8d4bc5855f49174742f33.camel@fibraservi.eu \
--to=staf@fibraservi.eu \
--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