<falteckz>
o/ Hi all, I'm just recently bought my first FPGA (TinyFPGA BX) and am starting out with my first Verilog. I'm having a little clock hell and was hoping for help. I am using the PLL (generated with icepll) to upclock 16MHz to 48MHz for the USB peripheral, and now I want to try downclock the 48MHz to 12MHz to be my "everything else" clock.
<falteckz>
I tried to keep the "everything else" clock at 16MHz but when I added clock constraints to nextpnr it was only 41MHz
Maylay has quit [Ping timeout: 260 seconds]
<falteckz>
I'm hoping that if I down clock the "everything else" then the USB can run at the full 48MHz
<falteckz>
I've used a /4 clock divider, which is just a two bit register. I suspect that will be implemented on fabric as two shift registers. But now I'm having difficulty getting nextpnr to constrain the two clocks. It's saying it's not finding my "clk12" net, which is the output wire of my divider. I think I know why, the clk12 is probably being optimized away. I read an issue on Github from whitequark saying that there is no functionality yet to force
<falteckz>
exposure of net names? So I've tried instead to map the clocks to the global buffer network on the iCE40. Sending clk48 to GBUF4 and clk12 to GBUF5. But still it wont constrain. I'll grab some logs.
<whitequark>
try adding (*keep*) on your clk12 net
<falteckz>
Oh
<falteckz>
Will try that!
<whitequark>
it's generally a bad idea to use FFs as clock dividers in real designs, but feel free to experiment with it
Maylay has joined ##openfpga
<falteckz>
I couldn't see anything else on hardware that would do the clock dividing for me, but I'm not familiar at all with the primatives available on the TinyFPGA BX
<falteckz>
I see get "Warning: net 'clk12' does not exist in design, ignoring clock constraint" with (*keep*) wire clk12;
<whitequark>
interesting
<whitequark>
can you upload the complete design somewhere?
<whitequark>
let me build the docker image and see...
<falteckz>
I suggest pulling it, build time is about 2.5 hours
<whitequark>
whatever is your build script doing by default
<whitequark>
[1/1] build: latest: Pulling from nevercast/tinysoc
<falteckz>
Oh cool, yeah. ./build.py interactive will put you in the container
genii has quit [Quit: See you soon.]
Maylay has quit [Ping timeout: 265 seconds]
<whitequark>
wow that's taking a really long time
<falteckz>
Sorry about the 6GB image, RISC-V toolchain is huge
<falteckz>
It's only the IMC version too!
<falteckz>
I assume it's still fetching the container?
<falteckz>
Oh there is a possible deadlock bug in my code that I've never seen happen but could happen. You could try `docker pull nevercast/tinysoc` first
<whitequark>
okay it uh... works now
<whitequark>
except it seems to have broken newlines
<whitequark>
like \n without \r
<falteckz>
Huh. I've only used the build script in cygwin on Windows, not tested elsewhere. So idk if it's just a hot mess for anyone else.
<awygle>
as a fellow cygwin user - it is a hot mess for everyone else.
<whitequark>
hang on, edif?
<whitequark>
why are you using edif?
<falteckz>
[1/1] build: Warning: Ignoring conflicting 'keep' property on net clk12. Use -keep to generate the extra net nevertheless.
<whitequark>
nvm, that's just fusesoc being silly i think
<falteckz>
So my build script and stuff is just fusesoc and blink janked together with TinyFPGA BX example. If the build process is entirely borked, I'm not surprised.
<falteckz>
There were a lot of square peg round hole moments
<whitequark>
i find fusesoc somewhat opaque...
<whitequark>
adding docker doesn't really help things
<awygle>
i like fusesoc but it has certain design constraints that make it perhaps not ideal for learning
Maya-sama has joined ##openfpga
<falteckz>
The apparent nested black box problem is clear to me. I just kinda charged forward with "make it work"
<whitequark>
yeah not saying it's wrong
<whitequark>
it's just that i can't make heads or tails of it at the moment
<whitequark>
can you upload nevercast_tinysoc_tinysoc_0.1.json ?
<whitequark>
so the nets actually exist in the json
<whitequark>
no idea what's happening here, report a nextpnr issue?
bibor has quit [Ping timeout: 272 seconds]
bibor has joined ##openfpga
Maylay has joined ##openfpga
<falteckz>
[1/1] build: ../src/nevercast_tinysoc_tinysoc_0.1/tinysoc.v:60: Warning: Range select out of bounds on signal `\counter': Setting result bit to undef.
<falteckz>
Found it -.-"
<falteckz>
Info: Max frequency for clock 'clk12_$glb_clk': 23.27 MHz (PASS at 12.00 MHz)
<falteckz>
ERROR: Max frequency for clock 'clk48_$glb_clk': 39.76 MHz (FAIL at 48.00 MHz)
<falteckz>
At least the netlist is working, I guess.
<falteckz>
Is there a way to create a boundary between two modules? The 48MHz stuff and the 12MHz stuff don't really need to interact. I've no idea why it's having difficulty running at 48MHz! It runs at like, 100MHz with the 12MHz logic disabled; and apparently that passes timing
<falteckz>
I assume I should study the critical paths. But what seems like simple separation of concerns in my own theory obviously has catastrophic costs in practice
<falteckz>
Seems the routing cost goes up for the USB (48MHz) when I enable the 12MHz logic. I assume that is what kills my timing budget. Can nextpnr prioritize the timing of a net or specific path?
<tnt>
What fpga is that ? And what code/repo ?
<awygle>
tinyfpga bx
<tnt>
And are you sure that when you "disable" the 12M logic it just doesn't end up optimizing a bunch of your 48M stuff away ?
<falteckz>
I'm quite sure, because the two modules don't touch each other at all
<falteckz>
I can verify it if you think that the modules having no nets in common could still have an effect.
emeb_mac has quit [Quit: Leaving.]
<tnt>
No, I just had a quick look at the code above and seems fine.
<tnt>
And do you have a log of when it meets 100 MHz ? Because looking at the critical path, the ratio logic/routing seems fine so it's not that limited by being full I think. And the logic delay would be the same for the same synthesis result.
<falteckz>
I see no memories are used, I wonder how much is being used for RAM and I suspect that's being implemented on FF
<falteckz>
I'll gen a log without the picorv32/12MHz logic
<tnt>
No memories ? SB_RAM40_4K 22 ??
<falteckz>
Sorry, I saw "Number of memories: 0
<falteckz>
" and took that in faith
<awygle>
i wonder if "PLL has LOCK output, need to pass all outputs via LUT" is relevant? that sounds kind of troubling but idk what it exactly means
<falteckz>
I do see what you mean about SB_GB, they are used up entirely by USB when available
<falteckz>
When the CPU is in use, the div and mul logic uses the SB_GB
<falteckz>
Perhaps I can force the USB IO to use the global network?
<tnt>
I doubt that would help ... none of the nets have that high a fanout.
<tnt>
And tbh getting on the global network can add more time to get to the buffer than it gains using it.
<tnt>
But it's 56 MHz, ... quite far from 100M. 56 -> 42 isn't that surprising going from 12% usage to 86% usage.
<tnt>
Did you try different seeds ?
<falteckz>
I've not tried seeds, no. Will give it a go
<falteckz>
I thought I got 100M earlier, not sure what I did to do that.
<falteckz>
Maybe that was before my blinking led
<tnt>
also did you try without '--opt-timing' not sure that helps that much.
<falteckz>
I did try without it, it made about 1MHz difference in the positive direction
<falteckz>
(faster when using --opt-timing)
hitomi2500 has joined ##openfpga
<falteckz>
If I rip out the blinking LED I get 51MHz on the USB, and 100MHz on the clk12.
<falteckz>
But, that's a pointless change. At least I know how "100M" got in my head
<falteckz>
I see that I haven't added any peripherals yet and I'm at 5k/7k LUT, oof
Maya-sama is now known as Miyu
OmniMancer1 has joined ##openfpga
Bird|otherbox has quit [Ping timeout: 246 seconds]
OmniMancer has quit [Ping timeout: 264 seconds]
OmniMancer has joined ##openfpga
OmniMancer1 has quit [Ping timeout: 260 seconds]
<falteckz>
Is it theoretically possible to place and route two "blocks" or "regions" of HDL separately. Can I tell a PNR to just "make sure these nets go fast" and "don't worry if these nets are slow af" ?
<falteckz>
I feel so naive, but part of me is yelling "surely this is the autorouters fault"
<mangelis>
it would be sometimes nice if you could incrementally PNR blocks and only "link" them with not-so-optimal connections
<mangelis>
although it has been a lesser problem since moving to nextpnr because it's so blazingly fast compared to vivado
<whitequark>
iirc the problem is that hard IP can't be done that way
<whitequark>
so you'll be limited to LUTFF, and sometimes not even that is easy
<whitequark>
if you have irregular fabric
<falteckz>
I'm honestly struggling now, I'm pages deep in PDFs reading about optimising verilog. Though since my code is just glue at this stage, it's all third party stuff that will need the optimisation
<whitequark>
third party code?
<falteckz>
Usbserial and picorv32 are the two components of my project that are causing timing trouble
<falteckz>
They are OSS sure, but they are also mammoths for what is my first week coding HDL
<whitequark>
drop usbserial
<whitequark>
you really don't want to get into debugging USB
<whitequark>
ideally ever but very certainly in your first week
<falteckz>
But now usbserial works with Windows' CDC driver, so that's neat
<whitequark>
it's a tinyfpga bx, right...
<falteckz>
Yes
<whitequark>
grab an USB-UART adapter somewhere
<falteckz>
It's certainly the less pretty option that everyone else is doing.
<falteckz>
I've a Silabs micro usb uart breakout somewhere
<whitequark>
people are doing that for a reason
<whitequark>
USB is hell, and having USB as a critical part of your FPGA design is double hell
<falteckz>
I guess I was a fool to think that once I had solved USB, and I did btw, I fixed USB; that it wouldn't break in the future
<whitequark>
using something like usbserial in an FPGA design is roughly equivalent to having some Python code in your hot path
<whitequark>
you *can* get it to work if you have really good skill and patience but it won't be for very long
<falteckz>
Hahah
<whitequark>
and it won't interact nicely with the rest of your stuff
<falteckz>
The irony is not lost that I write MicroPython as my day job
<whitequark>
yeah that's kinda similar actually
<whitequark>
there is a certain... convenience to it
<falteckz>
There isn't. You think there is, and then 4 months later there isn't /bitter
<falteckz>
I'll apply the same to usbserial, pull it out.
<falteckz>
It's just so sexy, bitbanging USB
<whitequark>
yep
<falteckz>
I wish I could understand why the timing failed, my docker container doesn't afford me any gtk view
<falteckz>
Can a graph be rendered to png? What would do that, Yosys?
<whitequark>
i don't really use the gui tools
<falteckz>
Then you'd be the person to ask; any visualisation of the LUTFFs and wires?
<falteckz>
(without gui tools)
<kbeckmann>
yosys show can generate a dot file for you
<kbeckmann>
then you chould render that in your host machine
<tnt>
whitequark: heh, I have usb working just fine ... the usbserial from tinyusb is just quite a bit hackish.
<falteckz>
What's your resource utilisation, tnt?
<tnt>
falteckz: and it fails timing because it has horribly long comb path that rely on the placer/router to do an exceptionally good job to meet timing.
<falteckz>
It's only the USB decoding that needs to happen at 48M anyway, so surely a pipeline in the right place, and move most of the usbserial to a lower clock speed, boom, not broken
<tnt>
falteckz: I made picorv with usb core work just fine at 90% LC usage in a up5k.
<falteckz>
That's a hope for the future, but unless I see something jump out at me, I might carry on the less sexy way for now. Need to get some peripherals put together
<falteckz>
But darn I really want usbserial to work
<tnt>
you could also just ignore the timing error tbh ... the fpga is probably a good 50% faster than the worst case timing reported by nextpnr.
<tnt>
not best practice, but you can revisit the issue later / add pipelining / ...
<tnt>
Also, I actually recently made USB RX clock recovery work just fine at 36 MHz instead of 48 MHz (so 3x oversampling instead of 4x) so that's another option.
<falteckz>
If it was in logisim I could fix it :'D
<whitequark>
tnt: oh you can def make it work
<whitequark>
it is just hell
Asu has joined ##openfpga
<falteckz>
Anyone have a module that'll join two valid/ready interfaces and buffer/pipeline them?
<falteckz>
I've started writing one but surely one exists that doesn't have bugs
<tnt>
I don't have one handy, but if it's for the usb in/out ports, given that you can't get anywhere close to max rate, you can easily make one that only does half rate.
<falteckz>
Even if I clock the FIFO with 12MHz, do I still have a CDC problem?
<falteckz>
I can just solve that with more FIFO right?
<falteckz>
"solve" => problem becomes insignificant enough to ignore
<falteckz>
Actually I probably don't have a CDC problem because I'm using FFs to drive the 12MHz signal anyway heh
<zyp>
whitequark, I disagree, USB is fun :)
<whitequark>
hell can be fun
<whitequark>
for example, i am voluntarily cross-compiling boost today
<zyp>
ha, that does not sound fun
<whitequark>
;)
<zyp>
but what do you have against usb anyway?
<falteckz>
inb4 scars and battle wounds
<zyp>
I've been playing around with a usb core of my own recently, and so far I feel it's been a pretty painless project
<whitequark>
oh, nothing, it's just one of the worst notable buses ever designed
<whitequark>
a constant series of fuckups that end up being incompletely fixed in the upper layer and/or next version
<whitequark>
starting with the ridiculous pseudo-differential physical layer and going all the way through usb 3 "streams"
<whitequark>
the only good parts of usb are those it cribbed from PCIe, and i guess HID is fairly reasonable
<falteckz>
Do the streams work the similar to HTTP2 ? i.e. out of order, round robin delivery of multiple connections?
<whitequark>
similar
<falteckz>
Sounds like hell to implement
<whitequark>
they're heroically solving a problem that shouldn't have existed in first place
<falteckz>
I feel like that right now
<whitequark>
take a look at the ethernet encapsulations some day; there are three incompatible *standard* ways alone
<falteckz>
I'm not even sure my FIFO isn't going to explode
<whitequark>
four if you count RNDIS, which you better, if you want windows anyway
<whitequark>
the storage encapsulations are all "how can we make SCSI worse"
<whitequark>
the audio stuff can be used as a teaching material in how not to design interfaces
<falteckz>
Heh I saw that USB Type C has a pure analog mode
<whitequark>
that one's actually ok
<tnt>
falteckz: you most definitely need proper CDC between 12M and 48M domain ... _especially_ if your 12M is manually generated from a FF divider with completely random phase relationship with the 48M domain.
<whitequark>
oh yeah type-c
<whitequark>
"what if we put ethernet in the usb cable"
<whitequark>
"except in the least useful possible way"
<falteckz>
tnt: Surely the 12M phase is at worst, lagged behind 48M
<whitequark>
it's fractally aggravating
<whitequark>
falteckz: it doesn't work that way
<whitequark>
it's like UB
<falteckz>
Which doesn't sound so bad, that's just day to day gate propagation life
<whitequark>
if it's not explicitly allowed, it's forbidden
<falteckz>
Oh
<falteckz>
But, gates have lag anyway, that's what the critical path is all about?
<falteckz>
Right?
<whitequark>
yes, but nextpnr doesn't consider paths between clock domains
<whitequark>
so you have to assume they're just completely asynchronous
<whitequark>
if you transfer a bus you can have setup/hold violations on half the bits
<tnt>
falteckz: it's a periodic signal ... "lagged behing 48MHz" is jus some nanosecond away from being just before the next edge.
<falteckz>
Not just some, like, 20 nanoseconds or something
<falteckz>
Oh right, multi bit busses
<falteckz>
GAH
<zyp>
whitequark, why does it matter that there's four ways to do ethernet over USB? just do NCM and forget the others
<zyp>
whitequark, I don't mind there being four ways to skin a cat as long as one of them works for me, it's better than a «one size fits none» solution
<whitequark>
zyp: because it shows how dysfunctional the ecosystem is
<falteckz>
They probably use the term "unopinionated design"
<whitequark>
that you are able to solve your single use case says absolutely nothing about USB besides "it is not completely unsuitable for the task"
<tnt>
Well, There is as many way to do ethernet on PCIe as there is ethernet controller chips :p
<falteckz>
It totally zapped my mind that FPGAs are fast enough to do PCIe
<falteckz>
Ohboi
<whitequark>
the particularly tragic thing about USB is that both Ethernet and SCSI are far better designs that it poorly encapsulates
<whitequark>
tnt: there ought to be an XHCI equivalent for Ethernet, I agree entirely
<whitequark>
falteckz: they're ... not quite
<falteckz>
What's a motherboard divider again?
<whitequark>
for ECP5, PCIe Gen2 is really stretching the capabilities of the chips
<falteckz>
The last time I thought about interfacing with a motherboard expansion port, I could still poke the screen buffer from userland. So yeah - not disappointed that I'm still wrong on that one
<tnt>
whitequark: that reminds me of the freescale mpc5200 where they implemented ohci spec but with the wrong endianness of the registers ...
<whitequark>
lol
<whitequark>
i guess my summary of usb is: the one good thing i can say about it is that it mostly works
<whitequark>
this is the highest standard many people apply but this does not even make my lowest standard
<whitequark>
hence the confusion
<azonenberg>
whitequark: lol
<azonenberg>
the one good thing i can say about USB is that I haven't had it start any fires in my lab yet
<azonenberg>
:p
<whitequark>
ouch
<azonenberg>
not that i've had any from other causes, but...
<azonenberg>
it's about the only positive thing i'm willing to say. Lol
<zyp>
the way I see it, USB is the best solution to a lot of problems
<azonenberg>
No
<whitequark>
^
<zyp>
calling usb bad is unproductive when everything else is worse
<azonenberg>
it's the least bad solution in a few narrow cases
<whitequark>
^
<falteckz>
Max frequency for clock 'clk48': 44.74 MHz (FAIL at 48.00 MHz)
<falteckz>
Getting closer!
Mimoja2 has joined ##openfpga
<azonenberg>
Ethernet is almost universally superior
<whitequark>
"criticizing a bad design is unproductive" is bullshit
<falteckz>
^ I agree that it's bullshit
<whitequark>
this is like saying "C is least bad solution to many problems, therefore everyone should not criticize C"
<whitequark>
which is something a lot of people do say
OmniMancer1 has joined ##openfpga
<azonenberg>
whitequark: btw speaking of c, one of these days i want to try out an idea i've had for a while
Mimoja has quit [Quit: Ping timeout (120 seconds)]
Mimoja2 is now known as Mimoja
OmniMancer has quit [Ping timeout: 265 seconds]
<falteckz>
That's an unfortunate thing to say - nothing is immune to criticism
<whitequark>
no. i will criticize bad designs, and i will either work on better ones, or inspire people to do that
<azonenberg>
namely, formalizing my "C+" language concept a bit more and enforcing it at the compiler
<whitequark>
azonenberg: what do you mean by "C+"
anuejn has quit [Quit: No Ping reply in 180 seconds.]
<azonenberg>
i firmly believe it is possible to create a strict subset of C++ that is memory safe and free of a lot of the problems plaguing full C++
anuejn has joined ##openfpga
<azonenberg>
but is just as expressive and almost as fast as vanilla C++
<whitequark>
that seems like an incredibly miserable hill to die on but i look forward to seeing your results
gtw has quit [Ping timeout: 265 seconds]
gtw has joined ##openfpga
<azonenberg>
among other things i propose to ban use of raw pointers and only allow use of refcounted/bounds checked smart pointers that can be either created as is, or wrap external mmio or library provided pointers
<whitequark>
references?
<azonenberg>
using templates when possible if the size of an array is known at compile time, so you can statically optimize out bounds checking when the index is known to be within th ebounds
<azonenberg>
I probably would allow const references but disallow holding onto them after the function in question returned? not sure about that yet
<azonenberg>
it's just a concept at this point
<whitequark>
you're reinventing rust
<q3k>
it's like you're 30% of the way there to reinventing the borrow che...
<q3k>
yes
<whitequark>
which, i mean, is not inherently a bad idea
<whitequark>
you absolutely could reinvent rust on top of c++
<azonenberg>
not quite. rust is too strict and handicaps you. And it's not OO
<azonenberg>
I don't want to be coding in a padded cell
<azonenberg>
I want C++ with a guardian angel that saves me when i do something stupid
<whitequark>
you're going to discover very quickly why rust looks like that once you try to formalize your semantics
<azonenberg>
but otherwise lets me pretend i'm just writing c++
<whitequark>
i went that route. if i understand what you want correctly, it's not feasible as described
<azonenberg>
if there was a fully OO version of rust with multiple inheritance etc, i'd seriously consider using it
<azonenberg>
but i also want to allow pointers (not references) to be used freely and passed around as you see fit. rust's ownership semantics were much too strict for me
<azonenberg>
i'd rather prevent UaF by refcounting, and ensuring that it's imposible to have a pointer to something without also having a ref
<azonenberg>
i.e. once memory is freed it's guaranteed there's no pointers to it
<azonenberg>
also my proposal allows full use of c-style pointer arithmetic while also preventing access to invalid indexes
<azonenberg>
since every pointer object is tagged with min/max values for the allocated block
<azonenberg>
you can do any math you want as long as the result is still in that range
<q3k>
azonenberg | i'd rather prevent UaF by refcounting, and ensuring that it's imposible to have a pointer to something without also having a ref
<q3k>
i mean you can just use Rc and Arc everywhere in rust
<q3k>
and never have to worry about the borrow checker
<whitequark>
also that
<zyp>
azonenberg, I feel like ethernet are solving different problems than usb, kinda like how bluetooth and wifi are solving different problems
<whitequark>
bold of you to imply bluetooth is solving any problems
<azonenberg>
whitequark: it's keeping my coworker employed
<zyp>
s/solving/addressing/
<azonenberg>
that's a valid problem to solve :p
<whitequark>
lol
<azonenberg>
somebody has to pentest all of those iot crap gadgets
froztbyte has quit [Ping timeout: 260 seconds]
<whitequark>
zyp: ethernet and usb don't solve the exact same problem
<azonenberg>
zyp: ethernet is being used to solve different problems from usb
<q3k>
capitalism is a pyramid scheme
<zyp>
that's exactly what I'm saying
<whitequark>
but you could use most of the ethernet to replace most of usb and it'd work better in every respect
<azonenberg>
but i continue to have a vision of a compact ethernet connector (smaller than 8p8c) with either poe or standalone parallel DC power
<azonenberg>
run ipv6 on a link local subnet for talking to peripherals
<azonenberg>
optionally give them routable addresses so that the prnter plugged into your pc can be bridged to the lan, etc
<azonenberg>
i think ethernet could replace usb and work better
<whitequark>
you do need plug&play and power
<zyp>
agreed
<azonenberg>
whitequark: yes, either poe or parallel dc power would work. it'd need to be a custom connector i think as 8p8c is a bit large
<whitequark>
for glasgow revE i'm going to use usb as purely an ethernet condoit
<azonenberg>
but one could easily define an ethernet based plug and play API
<zyp>
what ethernet lacks that usb has is a lightweight enumeration protocol and a cheap phy layer
<azonenberg>
zyp: 10baseT isn't cheap?
<azonenberg>
you can bitbang it on anything
<azonenberg>
an enumeration protocol could easily be defined on top of ethernet or IP
<azonenberg>
my biggest gripe is with the usb 1.x/2.x PHY
<azonenberg>
it's a giant pain in the butt and the ethernet PHY is beautiful by comparison
<q3k>
OSPFv6 as an enumeration layer
<azonenberg>
dont get me wrong, i have a few complaints about the 100baseTX PHY as well, but it's nothing compared to the sheer burning hate i have for usb
<q3k>
(with LL addresses)
<zyp>
s/cheap/cheap and common/
<zyp>
from a software perspective, I don't wanna bitbang anything, I wanna send and receive frames
<whitequark>
you don't bitbang usb either
<zyp>
exactly
<whitequark>
the point of "you can bitbang 10baset on anything" isn't that you should do it
<whitequark>
it's that the amount of logic necessary is minimal
<azonenberg>
exactly
<azonenberg>
let me put it this way
<azonenberg>
i implemented a stripped down form of 10baset autonegotiation and link keepalives once
<azonenberg>
... on a GREENPAK
<azonenberg>
20-something luts and a few hard ip counters
<azonenberg>
it was able to link up with my cisco and negotiate 10M/full and keep the link up. didn't have the gates to send any data but manchester coding is cheap
<azonenberg>
a second greenpak probably could have done a full tx-only 10baset phy :p
<zyp>
does 10base-t do single pair HDX?
<whitequark>
no but there's a new (very new) similar standard that does single pair
<azonenberg>
i'm waiting for my new packet sniffer to come in from oshpark :p
<gruetzkopf>
heh, the fastest optical standard i have any chance of capturing with my equipment would be STM-1
<azonenberg>
i wanted to write a scopehal protocol decoder for 1000base-X and this seemed like a reasonable enough way to do it :p
<azonenberg>
monochroma and lain have a 5 GHz scope that i'm hopeful will be able to sniff 10Gbase-R with this fixture
<azonenberg>
it's technically 5.15625 GHz but that's close enough to the b/w rating that it should (?) work
<azonenberg>
it'll be >3 dB attenuated and look like a sine wave
<azonenberg>
but hopefully will be readable
<azonenberg>
but with my 2 GHz scope, 1000base-X should be easily readable
<gruetzkopf>
i still need to try out rigol+glscopeclient, 100BASE-TX is very easy to see on that one (even 1GBASE-T if running single-channel, but that's far beyond rated BW)
<azonenberg>
gruetzkopf: i have a 100base-tx protocol decode that should work
<azonenberg>
the only challenge is triggering
<azonenberg>
since there's continuous idles between frames
<azonenberg>
but if you have some way to know when there's a frame on the wire, like sniffing a phy pin or something, you should be able to grab it
<zyp>
speaking of protocols, I've been wondering what would be good for a management interface over a backplane
<zyp>
management and async data exchange
<zyp>
almost tempted to do something like 100BASE 8b10b over M-LVDS
<azonenberg>
So for the MARBLEWALRUS project i never ended up building
<azonenberg>
i had put a fair bit of thoguht into this
<azonenberg>
each card had an i2c bus for temp/voltage/current sensors, a uart for console, JTAG for debug, then 1000base-X as the primary user design communications interface
<azonenberg>
all on a pcie edge connector
<zyp>
I'm still just looking for a sideband interface though
<gruetzkopf>
my IBM bladecenters uses RS485 (poorly)
<gruetzkopf>
T1S would be near-ideal (if not a bit slow) if it were available
<zyp>
yes, T1S and CAN FD are prime candidates
<gruetzkopf>
the few T1S phys i've seen so far support CANFD phy operation :D
<whitequark>
do you have any phys?
<whitequark>
like actual chips
<gruetzkopf>
no
<gruetzkopf>
not even the two switch vendors i've talked to have
<whitequark>
ouch
<OmniMancer1>
I have to feel that every peripheral implements IPv6 is a good way to get N variously buggy implementations of IPv6 and rapidly have everything pile up with workarounds you need if you want any reasonable compatability with peripherals
<OmniMancer1>
Also unsure how such things fare on the peripherals should be cheap to produce axis
<whitequark>
i'm not sure that you want IPv6 specifically
<falteckz>
Alright... managed to get the USB clock as high as 46MHz and decided to rip it out haha
<falteckz>
I'll play with it another time and/or rewrite it myself to be more lean
Bird|otherbox has joined ##openfpga
Bike has joined ##openfpga
falteckz has quit [Ping timeout: 256 seconds]
X-Scale has quit [Ping timeout: 240 seconds]
peepsalot has quit [Read error: No route to host]
X-Scale has joined ##openfpga
Asu has quit [Read error: Connection reset by peer]
Asuu has joined ##openfpga
genii has joined ##openfpga
jfcaron has joined ##openfpga
peepsalot has joined ##openfpga
Thorn has quit [Read error: Connection reset by peer]
Thorn has joined ##openfpga
<OmniMancer1>
azonenberg: in your hypothetical C+ thing what happens when you call reserve on a vector while holding a pointer to one of it's elements?
<zyp>
presumably you can't, since that would be unsafe
<azonenberg>
yeah there's lots of open questions. It would be a research project more than anything else, to start
<OmniMancer1>
because that is basically one of the big things the borrow checker in Rust prevents and why it has the rules that feel restrictive, it also happens to make having thread safe abstractions easier
<azonenberg>
OmniMancer1: my tentative thought is that you would actually have more of a CoW type thing going on there
<azonenberg>
if you have a pointer to a block of memory and free it
<azonenberg>
you don't actually free it, you just unref it since that pointer is still able to use it
<azonenberg>
if you then reallocate a new block, you've effectively forked it
<azonenberg>
the old pointer is still valid and points to the old data
<zyp>
I'd say the easy solution is to forbid reallocations
<OmniMancer1>
so your solution is garbage collection :P
<azonenberg>
OmniMancer1: refcounting and gc are not the same
<qu1j0t3>
amen
<azonenberg>
there's no periodic collection of blocks with no refs
<azonenberg>
the act of dereffing a block frees it if you have the last reference
<azonenberg>
it's instant and occurs at predictable times, just like C memory management
<q3k>
>predictible
<q3k>
well
<q3k>
drop latency in rust is a thing
<azonenberg>
anyway, who knows if it will work
<q3k>
you drop the last ref, suddenly your code spends a bunch of time in free()
<azonenberg>
but it's something i want to experiment with as a research project at some point
<OmniMancer1>
Okay it may not be garbage collection in that way
<OmniMancer1>
but it is fundamentally similar to GC languages who solve memory safety of UaF by saying never free anything that is pointed to
<OmniMancer1>
q3k: there is a similar thing in C++ though with destructors no?
<q3k>
yeah but it's a bit more predictible
<zyp>
refcounting is also not a solution to everything, you can still leak memory through circular refs
<q3k>
yes
<q3k>
that's why doing safe rust for even things like a double linked list is weird
<zyp>
as I understand, that's also why python does a combination of refcounting and GC
<OmniMancer1>
yes it has a cycle collector
<OmniMancer1>
Oh also the fork and refcount thing also requires everything to be trivially copyable
<OmniMancer1>
which I guess if all pointers are refcounted is okay
<OmniMancer1>
but you now can't use destructors for resource management anymore
<OmniMancer1>
unless you forbid vectors from holding objects by value and only by reference
<zyp>
what about just forbidding vectors? :)
<q3k>
with time this will basically evolve to become a funny haskell
<q3k>
strongly typed, rc/gc, const lists only, lazy forking/evaluation, just have better object syntactic sugar than records and lenses
<OmniMancer1>
or a funny Java :P
emeb has joined ##openfpga
<q3k>
s,const,cons,
<OmniMancer1>
anyway it rapidly departs from being C++ which is kinda the point that people make about trying to make C++ safe
<zyp>
I tend to do C++ on bare metal without a heap
<zyp>
avoiding dynamic memory overall avoids most of the potential issues
<OmniMancer1>
not having allocation tends to avoid many problems
<OmniMancer1>
it makes a few of its own
<zyp>
and is entirely feasible for small bare metal projects
<zyp>
yeah
<azonenberg>
zyp: yes
<azonenberg>
most of my bare metal embedded stuff is no-heap
<azonenberg>
i actually wrote my own minimal printf because newlib's full printf requires dynamic allocation
<azonenberg>
and i didnt need to support every corner of the spec printing denormalized floats etc
<zyp>
IME the largest problem is inflexibility of containers
<zyp>
I generally end up with either fixed size arrays or intrusive lists
<azonenberg>
I don't use STL in my embedded work at all, at least at the moment
<zyp>
same
<azonenberg>
in fact i'm considering experimenting with a restricted version of my "C+" concept specifically for bare metal embedded
<zyp>
that's what I though you had in mind in the first place
<zyp>
thought
<azonenberg>
well that would let me eliminate a lot of problems
<azonenberg>
like third party libraries :p
<azonenberg>
Basically just doing bounds checking and a few other things to start
<cr1901_modern>
Aww, this looks like a neat langu- *sees #include "Cello.h"*
<cr1901_modern>
Oh no... oh no no no no NO!
OmniMancer1 has quit [Quit: Leaving.]
<Ultrasauce>
ah yes the classic 'half of c++ implemented with macros'
<Ultrasauce>
typedef void* var;
<q3k>
best type
<qu1j0t3>
i see it in TypeScript a lot
<cr1901_modern>
Couldn't they have extended a fork of pycparser or something and _then_ convert it to pure C code that the user nominally doesn't interact with?
<cr1901_modern>
I appreciate not wanting to write a parser, but...
<Ultrasauce>
yes static tooling is one of the major approaches to this sort of thing, see Qt
hitomi2500 has quit [Quit: Nettalk6 - www.ntalk.de]
<keesj>
what is a nice way to .. do platform specific stuff in verilog? I have my code that use SB_PLL40_CORE and some other custom blocks and I would like to lint it using verilator
<keesj>
iverilog that is
<Lofty>
`ifdef SYNTHESIS
<Lofty>
Wrap your custom block instantiations in that, I think
<keesj>
that appears to be working
emeb_mac has joined ##openfpga
<awygle>
there may also be a simulation model you can link, as another approach to investigate
befedo[m] has joined ##openfpga
befedo[m] has left ##openfpga [##openfpga]
<keesj>
currently I have a SB_PLL40_CORE and an SB_IO.
<keesj>
but i plan on writing more testbenched but also a top test bench. For top is it fine if the pll is not pll'ing
befedo[m] has joined ##openfpga
Asuu has quit [Remote host closed the connection]
Asu has joined ##openfpga
Thorn has quit [Read error: Connection reset by peer]
Thorn has joined ##openfpga
<zyp>
tnt, quickfeather turned up today :)
<tnt>
zyp: Ah, nice :)
<emeb>
still poking around on the SB_I2C core - got it hooked up to my riscv design in UP5k where the SB_SPI is already working so I know that the wishbone interface is good.
<emeb>
Seems that the Lattice documentation for this one has some errors
<emeb>
They imply that the SB_I2C in UP5k is similar to the one in Ultra Lite
<emeb>
but the register map I'm seeing looks more like the one in Ultra and LM
<daveshah>
The correct register map is not the FIFO one
<daveshah>
I think it is the Ultra and LM one
<emeb>
daveshah: yes - that's what I'm seeing.
<emeb>
but that's not what the Advanced Usage Guide says.
<daveshah>
Indeed, that is definitely an error
<TD-Linux>
my quickfeather package got torn open in shipping :(
<daveshah>
TD-Linux: that was a big problem with the original UPduinos
<emeb>
daveshah: ah - thanks.
<daveshah>
quite a few people actually got empty, torn envelopes, iirc
<TD-Linux>
given that it shipped from an address 15 miles away I'm half tempted to go over and ask for a replacement :)
<qu1j0t3>
TD-Linux: is it complete tho?
<TD-Linux>
no it's an empty envelope
<qu1j0t3>
yowsers!
<qu1j0t3>
you should be able to claim
Asu has quit [Remote host closed the connection]
<kc8apf>
huh, NXP LPC55S6x microcontrollers have 26 LUT5s and 4 FFs for customer use
<tnt>
4 whole flip flops ? woaw ...
<kc8apf>
yeah.....
<kc8apf>
they don't describe their inteded usage other than "state machines"
<kc8apf>
but they do provide a verilog-based toolchain
<awygle>
mmm state machines
<emeb>
lol, verilog for that.
<emeb>
palasm or cupl more like
<awygle>
lpc5500-series chips are cool
<awygle>
fun lil security bois
<kc8apf>
yep. looking into them for work
<awygle>
i suspected due to my keen intellect
<awygle>
your job sounds fun :( i should apply there...
<kc8apf>
"security" MCUs are still often distressingly bad at security
<kc8apf>
yes, you should
<noopwafel>
hey, at least you provide valuable amusement for attackers
<noopwafel>
if you use these things
<noopwafel>
I would also definitely be distracted from an attack by an MCU with random LUTs/FFs
<kc8apf>
true
<kc8apf>
could make a very annoying dependency for some critical op
<noopwafel>
nxp have some interesting random examples for use cases, like low-overhead stepper motor control with an emergency stop
<noopwafel>
and I can imagine it being nice to have some basic logic for wakeup
<noopwafel>
so now I have to buy some. thanks kc8apf :p
<kc8apf>
heh. It can also generate interrupts based on a boolean expression of up to 8 GPIOs
<kc8apf>
that's independent of the LUTs
<kc8apf>
fwiw, the configuration registers are documented with what appears to be enough detail for OSS tools
mumptai_ has quit [Quit: Verlassend]
jfcaron has quit [Ping timeout: 256 seconds]
Prf_Jakob has quit [Ping timeout: 260 seconds]
Prf_Jakob has joined ##openfpga
<emeb>
Curious behavior of the SB_I2C - I've got it starting to work, sending out I2C bus cycles on SCL & SDA and it doesn't see NACK conditions if it's completely unloaded. If I load the SCL line at all (scope probe, external pullup, etc) then it sees the NACK and goes into an error condition where SCL never stops running.
<emeb>
If I leave SCL unloaded then I can see the bus address and transmitted data bytes on SDA.
<emeb>
During the error condition the RARC and TROE bits in the status register are indicating the NACK, so it's detectable in software and if I poke the I2CBRMSB register then it will clear the error.
<emeb>
The other thing that's amusing is how long it takes for a bus cycle to be visible in the status reg - the TIP flag takes > 4us to assert after starting and the BUSY flag takes > 7us (when using a 100kHz I2C clock)
<emeb>
and if you don't update the I2CTXDR in time then it just keeps sending the same byte out until you do.