<vargheserijo[m]>
versions including 32 bit bus width, and eventually usb3.0/ethernet. Some work already done? I was thinking about it in my free time lately, do we see some prospects of this happening in the near future - and if there any any ways to collaborate? As I am late to the party, I might have missed out on same/similar discussions here, please bear that with me 😊
<vargheserijo[m]>
Hi, I am new to Glasgow. Recently stumbled upon this project and made one hardware for myself. Felt it to be a gem of FOSS projects out there, already used with some basic tasks but am aware of its capabilities. To me what’s stands out are the full opensource nature and freedom when comparing with other commercial offerings. Had a Chance to watch some videos in YouTube and got to know there were plans to introduce improved
<whitequark[cis]>
hi! glad you like it
<whitequark[cis]>
the 32 pin version is something that's been quietly under design for a while, the USB 3 one is something that's far off. collaboration on hardware is quite a hard problem and at the moment i don't think there are any opportunities to do so
<vargheserijo[m]>
No problem, and Thanks for the reply. It’s great to hear that 32 bit version is under development. For the new usb3.0 version you are planning, Was wondering if it’s a worthwhile pursuit to directly go for replacing ice40 with ecp5 and fx2 with fx3, thereby getting USB3.0 and more IO? I think a lot of porting work would be necessary! And porting FIFO to GPIF might be a pain in the neck! I believe that need for higher throughput
<vargheserijo[m]>
with USB3.0 is lacking currently among open tools that are available.
<whitequark[cis]>
FX3G1 is awful, FX3G2 and later are tolerable but there are many open design questions
<whitequark[cis]>
e.g. python can't really process USB 3 throughput unassisted
<whitequark[cis]>
it's not even yet clear which FPGA we'll uwe
<whitequark[cis]>
s/uwe/use/
<vargheserijo[m]>
Yes seems like these are real pain points right? And it becomes harder to stick on to the open philosophy, if one go with other fpgas, open tool chain supports for example yosis+nextpnr support also becomes a restraint, not to mention the performance penalty for python tooling.
<whitequark[cis]>
if we switch to xilinx it will be after we develop good OSS tooling first
<whitequark[cis]>
it's not just philosophy, shelling out to Vivado is a nonstarter
<whitequark[cis]>
do you have a lot of FX3 experience? that could be valuable
<vargheserijo[m]>
Not much on the software side. I know it’s fairly complex in the software side. I was thinking about ft601 as well, don’t know if you have considered that. Fairly inexpensive chip and need for no software (works as a simple FIFO), but at the costs of sticking on to their proprietary drivers and suboptimal portability also need for a softcore microcontroller core on fpga for enumeration/dac/adc/bus expander etc.. Worth mention is
<vargheserijo[m]>
lack of support for libusb, though there are ways to circumvent it.
<whitequark[cis]>
I want the device to be unbrickable and to do management of the board bus etc device side
<whitequark[cis]>
I think FT601 is out
<whitequark[cis]>
i've considered lots of options including LUNA and not one of them is obviously superior to others
<whitequark[cis]>
a Zynq or Zynq US with partial reconfig is high up there in terms of cost
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
<vargheserijo[m]>
These are unforgiving in terms of cost i think - again on open source tooling support - suboptimum I think. In my view, what makes Glasgow superior to other tools, among other features - it’s openness both in hardware, software and tooling - I am personally worried about it becoming another closed source tool in terms of locked up tooling. Also regarding the concern about ft601, may be I am missing the full picture but - I think
<vargheserijo[m]>
you can guarantee the in-brickbility of the hardware even by using ft601, provided there is a boot-loader kind on bitstream on fpgas eeprom (only used in the power on, used until applets are loaded) with which other applets can be loaded from host on bootup? Or am I possibly wrong here?
<vargheserijo[m]>
*non-brickability (if that’s a word at all) 😆
<whitequark[cis]>
to be clear, if we go with Zynq it means first taking a sabbatical to develop Zynq P&R
<whitequark[cis]>
I do not plan to ever require closed source tooling
<whitequark[cis]>
re "gold" bitstream, that is one way to implement the recovery process; I do think that a fully hardwired bootloader like that in FX2/3 is more reliable, but only marginally
<vargheserijo[m]>
Yes, absolutely. And if we choose an fpga like lfe5u-25f BGA381, we have enough resources to run a stripped down softcore risc-v cpu for board management - bit unconventional and risky I agree. But I think it is doable.
<whitequark[cis]>
ECP5 has no partial reconfig
<whitequark[cis]>
having two of them on board will balloon the cost
<vargheserijo[m]>
But one can get away with lack of partial reconfiguration- by making cpu softcore part of the „gold“ bit stream and also subsequent applet bit streams - I think technically it is possible.. it won’t consume a lot of resources, May be 3k LUTs likely..
<vargheserijo[m]>
* away with this lack of
<whitequark[cis]>
that isn't workable
<whitequark[cis]>
first of all it will balloon bitstream build times from "a few seconds" to "at least a minute"
<whitequark[cis]>
second, a core assurance you have right now is that certain protection functionality (power supplies, etc) cannot possibly be broken by writing a bad applet, by design
<whitequark[cis]>
third, the added complication of saving/restoring state of this softcore across reloads isn't something i particularly want to be solving; at that point just put an STM32 there
<whitequark[cis]>
(also i don't like softcores in general, i'd much rather implement stuff using logic)
<whitequark[cis]>
oh, also a final problem: where are you even putting the bitstream? flash? i don't like making the device wear out via normal use, also NOR flash is slow
<whitequark[cis]>
PSRAM could work but it adds complexity
<whitequark[cis]>
(and i dont think FPGA configuration will respect PSRAM duty cycle restrictions, even if it's proooobably fine in practice)
<whitequark[cis]>
the bitstream build times is probably the biggest practical issue right now, the added complexity of managing all the moving parts is the biggest barrier to shipping it
<whitequark[cis]>
I think the difficulty here is that you have many "technically possible" options--most of which I have seen deployed already--which I don't want to be on the bug report receiving side of
<whitequark[cis]>
the current architecture is incredibly reliable
<whitequark[cis]>
I want to preserve that
<vargheserijo[m]>
Yes that’s a reasonable concern. Thanks for clarifying in detail.
jfsimon1981 has quit [Remote host closed the connection]
redstarcomrade has quit [Read error: Connection reset by peer]
jfsimon1981 has joined #glasgow
jfsimon1981 has quit [Remote host closed the connection]
jfsimon1981 has joined #glasgow
<vargheserijo[m]>
Do you (and the community) mind if I do some prototyping in good faith in this direction? (Of course without infringing your trademarks and goodwill 😊)
<whitequark[cis]>
at the moment nobody is actively working on revE and we don't have enough information to decide on a specific design; so i think that's fine, given you coordinate with us
<whitequark[cis]>
the main concern i have is ending up having to support a de-facto fork if it becomes popular
<whitequark[cis]>
(fwiw, we don't have a registered trademark)
<vargheserijo[m]>
Thanks will co-ordinate with you. I set myself no high hopes of success, but trying out something ambitious. well, you might want to consider registering 😊
<whitequark[cis]>
it would set me back 10-20k USD, create additional privacy concerns (I have stalkers, multiple, who try to track me down), wouldn't do anything without active enforcement which costs more money, and create an obligation to enforce it which might mean ending up in a legal fight with someone well-intentioned but mistaken
<whitequark[cis]>
that seems like a net negative (also i've made zero USD from sales so i'd be spending my savings on it)
<benny2366[m]>
always wonderd why people would go that low , hope your fine ?
<whitequark[cis]>
it's OSHW
<whitequark[cis]>
being able to do that is part of the point
<benny2366[m]>
wait i'm speaking of the stalkers bit , so you lost me
<whitequark[cis]>
oh, stalkers
<whitequark[cis]>
mental illness, having nothing better to do with their life, messed up values
<whitequark[cis]>
shrug
<whitequark[cis]>
it's been going on for close to 8 years so i'm used to it
<benny2366[m]>
makes it worse tbh
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
<whitequark[cis]>
sazzach: thank you for doing the recent maintenance work, by the way! much appreciated, doing it alone is exhausting
sazzach[m] has joined #glasgow
<sazzach[m]>
No problem! I'm happy to/enjoy contributing.
<whitequark[cis]>
I'd like to invite you to the GlasgowEmbedded organization
<sazzach[m]>
I'd be honored
<whitequark[cis]>
done
<whitequark[cis]>
you'll have write access, meaning you could merge PRs by yourself
<whitequark[cis]>
the process is that all code is expected to be reviewed, but it can be reviewed after merging just like before. also, if something breaks useful functionality it just gets reverted no matter who committed it
<whitequark[cis]>
this process works fine for LLVM
<sazzach[m]>
Accepted!
<sazzach[m]>
And that sounds good RE reviewing. What would the process be for something like #989, where its a straightforward one line bug fix? Would I be good to / should I merge without involving you / other members?
<whitequark[cis]>
yes please
<sazzach[m]>
Sounds good!
<whitequark[cis]>
i invited you specifically because i trust your judgement in general
<sazzach[m]>
:)
<whitequark[cis]>
if we replicate the LLVM process exactly, then anybody who has one merged patch gets commit rights if they want. i'm fine doing that too, in all of the history of LLVM they've revoked commit rights only once
<whitequark[cis]>
it's just not something we've needed to formalize yet
<sazzach[m]>
Gotcha
jfsimon1981 has quit [Remote host closed the connection]
jfsimon has joined #glasgow
pyromuffin[m] has joined #glasgow
<pyromuffin[m]>
hello, i’m trying to figure out what the next step is after using the glasgow to find some JTAG TAPs. I have the data sheet and the IR codes, so i guess how do i get the glasgow to actually start issuing commands? is the point at which i need to start writing scripts? i’m confused where the python api/applet distinction is. thanks.
<pyromuffin[m]>
* commands? is this the point
<whitequark[cis]>
can you give me an example of what you'd like to do so i can give you a concrete answer?
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #glasgow
jfsimon has quit [Max SendQ exceeded]
jfsimon has joined #glasgow
<whitequark[cis]>
pyromuffin: anyway, i would suggest doing `glasgow repl jtag-probe <options you got from jtag-pinout>` and then doing `help(iface)`
<whitequark[cis]>
you'll need the bits class, which you can get as from glasgow.support.bits import bits
<whitequark[cis]>
then you can do something like await tap_iface.test_reset(); await tap_iface.write_ir(bits("1100")); await tap_iface.run_test_idle(1)
<whitequark[cis]>
once you have more than just a few function calls, i would suggest putting it in a file and doing `glasgow script file.py jtag-probe <options>`
<pyromuffin[m]>
is that spy-bi-wire? i thought that was the name for the two wire jtag protocol. maybe there is more to it?
<whitequark[cis]>
(the branch is positively ancient but it shouldn't be too hard to upgrade it to the point where it works with current main; if you can't do that i will do it for you)
<whitequark[cis]>
SBW is Spy-Bi-Wire, yes
<whitequark[cis]>
do you want to use the 4-wire variant? if so, you'll have a bit of trouble, because of the "noncompliance with IEEE 1149.1"
<pyromuffin[m]>
All right, if that has an msp430 debugger i’ll take a look. I am not using the applet. and I am using 4 wire.
<whitequark[cis]>
it's not a complete debugger, it's a very rough sketch of one
<pyromuffin[m]>
the chip i have is quite old and I don’t think has sbw, but I am not sure.
<whitequark[cis]>
the MSP430 "JTAG" (not actually JTAG, even in the 4-wire variation) is absolutely vile
<whitequark[cis]>
it's incredibly difficult to get right and I actually just gave up 6 years ago
<whitequark[cis]>
if you want to use the 4-wire variant you will have to figure out a way to toggle TDI without toggling TCK in order to clock the CPU core
<whitequark[cis]>
normal JTAG devices aren't supposed to care, which is why the jtag-probe applet doesn't provide this functionality
<pyromuffin[m]>
ah, ok that’s good to know.
<pyromuffin[m]>
it seems this will be less trivial than i had hoped
<whitequark[cis]>
it's what i would describe as "a fun research project"
<whitequark[cis]>
if you aren't very skilled in the art it might make you want to quit the field
<pyromuffin[m]>
i’m not a stranger to embedded protocols and fpga dev.
<whitequark[cis]>
then you can probably do it, but it'll be frustrating
<whitequark[cis]>
an additional source of potential frustration is that right now we're doing a refactoring and there's an outstanding PR that will change how the jtag-probe applet works internally, in a way that changes how it'd be reused in a custom wrapper that lets you toggle TDI
<pyromuffin[m]>
all right. thanks for the pointers, and uh, encouragement.
<whitequark[cis]>
hah, sorry to rain on the proverbial parade, but i want to be very clear on how difficult and finicky this task is
<whitequark[cis]>
there are algorithms MSP430 requires that are expressed in terms of half-cycles of the CPU clock
<whitequark[cis]>
if you get even a single edge wrong it just doesn't work and you can't tell why
<pyromuffin[m]>
that’s fair.
<whitequark[cis]>
at the time i think i spent something like two weeks trying to make it work and in the end i could get it to work on some chips but not others
<whitequark[cis]>
to this day i don't know why
<whitequark[cis]>
with six years more experience i could probably figure it out
<whitequark[cis]>
this happened because the JTAG scan chain in MSP430 cuts through the internal CPU bus (if you look at it under SEM you can see where they hand-inserted the cells)
<whitequark[cis]>
so it was never really "designed" as a debug module
<pyromuffin[m]>
from my reading it seems there’s some funny business with the jtag fuse testing toggle, depending on model
<whitequark[cis]>
iirc i got that right and the issues i hit were related to the CPU core not ending up in the right state
<pyromuffin[m]>
ah, i don’t have any insight into that.
<whitequark[cis]>
i did get as far as reading target memory
<whitequark[cis]>
so in theory, if you forward-ported that and then adapted it to 4-wire debug interface, you should be able to dump it
<whitequark[cis]>
if you're very lucky then you might be able to do it in a day of work
<whitequark[cis]>
but this would be in the case where you don't get stuck on anything else and all of the existing functionality happens to work right away
<whitequark[cis]>
is your device 430, 430X, or 430Xv2?
<pyromuffin[m]>
430F4
<pyromuffin[m]>
yeah i expect it will take me longer than a day to figure out the general glasgow workflow and hdl
<pyromuffin[m]>
i’m coming from xilinx and scala
<whitequark[cis]>
okay, this is "family 1xx" and "core 430" or "core 430X" (not sure why)
<whitequark[cis]>
both are supported in the branch
<whitequark[cis]>
re glasgow workflow: probably the most unusual thing to learn will be that we treat a netlist/bitstream as a disposable, built-on-demand (in seconds) intermediate product
<pyromuffin[m]>
yes i was quite impressed by that !!
<whitequark[cis]>
thanks ^^ it took a lot of work to get to this point
<whitequark[cis]>
the HDL is conceptually slightly lower level than Verilog since Amaranth doesn't have inference, I think coming from Scala you wouldn't have any issues learning it
<whitequark[cis]>
you're constructing a netlist parametrically from host language objects
<whitequark[cis]>
(we're migrating from V1 Applet API to V2 Applet API and both are currently undocumented, but V2 is much easier to learn)
<pyromuffin[m]>
all right, i can probably wait a few days for the merge, but i’ll check out that branch
<whitequark[cis]>
to answer your question about python API / applet distinction
<whitequark[cis]>
with the V2 API, there are three conceptual parts to a system when you
<whitequark[cis]>
* when you're running an applet
<whitequark[cis]>
you have the Glasgow library, which provides and encapsulates all of the necessary plumbing required to build a netlist, run it on the device, and connect to it via USB; the Glasgow CLI, which can enumerate every installed applet, parse the command line arguments, and instantiate the user's choice; and the applet itself, which consists of an "*Interface class" implementing a, well, interface to some hardware, and a "*Applet" class
<whitequark[cis]>
that is instantiated by the CLI and in turn instantiates the "*Interface class"
<whitequark[cis]>
the user interface has two aspects or tiers to it: you can interact with the "*Interface class" directly, using either the REPL, the script mode, or by instantiating it directly (see the examples/applet_without_cli.py); or you can interact with the "*Applet class" via the CLI by providing it a command line
<whitequark[cis]>
during development you would typically copy the boilerplate over and start developing the "*Interface class", then wrap it into a "*Applet class" once you have enough functionality that it makes sense to expose a high-level view of it
<whitequark[cis]>
the V1 API did not have such a clean separation of concerns and especially making applets that are based on another applet (like something that uses JTAG) involved very cursed Python code
<pyromuffin[m]>
i see. Thanks for the explanation. I didn’t see those example scripts before.
<whitequark[cis]>
the concept behind the V2 API is to enable you to compose code like Lego
<pyromuffin[m]>
haha, I have heard promises of this in many software fields and somehow it’s never quite that easy.
galibert[m] has joined #glasgow
<galibert[m]>
Yeah, but Cat is good at that
<whitequark[cis]>
I think we're actually doing pretty well in terms of composition
<whitequark[cis]>
definitely not perfect, the main two pain points being "packing multiple data pipes into one is still not implemented, and defining a happens-before relationship that lets you avoid race conditions without absolutely killing performance is hard", and "we don't have a pin mux abstraction"
redstarcomrade has quit [Read error: Connection reset by peer]
<pyromuffin[m]>
i the details. I have a lot to look into for now. I find this kind of thing to be a fun puzzle. Hopefully I’ll be able to contribute if i manage to make it work.
<pyromuffin[m]>
* thanks for the details. I have a lot to look into for now. I find this kind of thing to be a fun puzzle. Hopefully I’ll be able to contribute if i manage to make it work.
<whitequark[cis]>
yep, I'd be happy to have a functioning MSP430 applet
<whitequark[cis]>
I do have a high bar for quality for in-tree applets since generally we commit to maintaining these things forever
<whitequark[cis]>
we have a testing infrastructure that reduces the need for having a HIL testbench these days
<pyromuffin[m]>
oh neat. I’ll be interested to see how that works. maybe I can learn some things for my work work.
<whitequark[cis]>
you give it a dotted path to the "*Interface class" and it captures all method calls and records their result
<whitequark[cis]>
then on the next invocation, it checks the arguments against a file, and returns the results from the file also