<edmoore>
awygle: i think nuclear thermal has a useful future. it's a nice idea, good T/W and twice the Isp of chemical
_whitelogger has joined #yosys
lutsabound has joined #yosys
TudorTimi has joined #yosys
philtor has quit [Ping timeout: 240 seconds]
<ZipCPU>
Welcome, TudorTimi to the #yosys channel!
massi has quit [Remote host closed the connection]
seldridge has joined #yosys
<awygle>
edmoore: only the scary versions have good T/W though, right? and the Isp is wimpy compared to ion drives. i'm more bullish on things like VASIMR
<edmoore>
i don't know of any non-scary versions :)
<edmoore>
but yes, the sort of minerva stuff from the 50s/60s
<sorear>
awygle: roughly how crank is DFD
<awygle>
sorear: i mean, it's not _crank_ exactly but my understanding is that it's as hard as any other fusion reactor if not harder
<awygle>
i need to put more time into reading about the PFRC to form a real opinion though
<awygle>
my current favorite fusion reactor designs are based on polywells as described by Robert Bussard
maikmerten has joined #yosys
lutsabound has quit [Quit: Connection closed for inactivity]
kerel has quit [Quit: No Ping reply in 180 seconds.]
danieljabailey has quit [Ping timeout: 240 seconds]
danieljabailey has joined #yosys
TudorTimi has quit [Remote host closed the connection]
dys has joined #yosys
emeb has joined #yosys
zkrx has quit [Ping timeout: 256 seconds]
zkrx has joined #yosys
dys has quit [Ping timeout: 260 seconds]
dys has joined #yosys
seldridge has quit [Ping timeout: 276 seconds]
seldridge has joined #yosys
<edmoore>
awygle: do you have a link to that?
<edmoore>
i admit some ignorance to a lot of the outré propulsion ideas because i've got enough on my plate to occupy lots of propulsion thinking as it is
<edmoore>
i did the sums to project daedelus (i mean just checking working rather than the original work) because alan bond was so involved with it
<edmoore>
my icestick has just arrived!
<awygle>
edmoore: to DMD or polywell?
<awygle>
polywell is primarily for energy generation rather than propulsion
<ZipCPU>
Yes, it is true, I've even watched shapr do cartwheels in a parking lot.
<ZipCPU>
He doesn't hide his addiction to cartwheels from anyone.
<edmoore>
i honestly wondered what a mountain unicycle was
<edmoore>
but that makes perfect sense
<edmoore>
is it practical for mountains?
<edmoore>
or is that a silly q
<edmoore>
oh shapr you are followed by dad piponi
<edmoore>
i think he's a good thing
<edmoore>
v interesting guy
kmehall has quit [*.net *.split]
<edmoore>
dan*
kmehall has joined #yosys
dys has quit [Ping timeout: 240 seconds]
jfng has quit [*.net *.split]
Nazara has quit [*.net *.split]
nurelin has quit [*.net *.split]
shapr has quit [*.net *.split]
Nazara has joined #yosys
pie_ has joined #yosys
<maikmerten>
does somebody know how to configure an iCE40 PLL to simply delay a pre-existing clock by e.g. ~2 ns?
<ZipCPU>
daveshah? I only know how to set up a given frequency, but I know the PLLs support more than just that.
<maikmerten>
I'd need to route the clock through the Fine Delay Adjust Control
<ZipCPU>
Isn't that also part of the PLL?
<daveshah>
Haven't don't that, but yes it should be possible with the built in delay control
<maikmerten>
I guess I'll just need to tinker around a bit
<daveshah>
Looks like you can add up to 16*150ps delay
<maikmerten>
yup
<maikmerten>
which should be plenty for my needs
shapr has joined #yosys
<shapr>
this is a test
<shapr>
whew, now I can speak again
<shapr>
edmoore: yeah, dan is a good guy, lots of fun to talk to
<shapr>
not sure any unicycles can be considered "practical" maybe commuter unicycles?
<ZipCPU>
You mean like 55mph unicycles?
NB0X-Matt-CA has joined #yosys
<shapr>
I don't remember the max speed of the commuter unicycles, but it's fast enough to be scary
<shapr>
I know 20mph is common, and 30mph is not rare
<shapr>
edmoore: how do you know dan piponi?
maikmerten has quit [Quit: Ex-Chat]
<edmoore>
oh just come across his work through two or three random contexts
<shapr>
film? math? physics?
<edmoore>
yes
<shapr>
haven't met him, but have been chatting with him for years
<shapr>
we had a fun twitter discussion about smartphone UIs recently
<edmoore>
e.g. my older supervisor also had a technical oscar and knew of him
<edmoore>
i found his blog in the context of prob distributions and haskell
X-Scale has quit [Ping timeout: 256 seconds]
[X-Scale] has joined #yosys
<edmoore>
my old*
<shapr>
oh yeah, I think we first started chatting via Haskell, I've been doing that for many years
<edmoore>
i'd like to get properly into haskell
<shapr>
one of my goals for learning FPGA design is to see if clash-lang has major advantages over verilog
[X-Scale] is now known as X-Scale
<edmoore>
but i think rust might have scratched my itch for enums + pattern matching (which i think is a superpower) and will run on microcontrollers
<shapr>
yeah, I still like FP, and Rust is imperative
<shapr>
I do like Rust also though :-)
zino has quit [*.net *.split]
marex-cloud has quit [*.net *.split]
dys has joined #yosys
<shapr>
I like languages that force me to rewire my brain to use them well. Haskell is one, verilog is another.
kuldeep has quit [*.net *.split]
dys has left #yosys [#yosys]
phire has quit [*.net *.split]
asy has quit [*.net *.split]
Kokjo has quit [*.net *.split]
pie_ has quit [Ping timeout: 265 seconds]
phire has joined #yosys
<shapr>
edmoore: I lost the channel history, did you get blink before steak?
dys has joined #yosys
<edmoore>
no my housemate started asking me about mosfets
<edmoore>
he is taking his first steps in electronics
<shapr>
oh interesting
<shapr>
I met my gf because she was looking for someone to teach her programming, now she's taking cybersecurity courses and doing data analysis
<shapr>
it's awesome to see people outgrow their teacher
zkms has quit [Ping timeout: 256 seconds]
kuldeep has joined #yosys
rqou_ has joined #yosys
rqou has quit [Ping timeout: 256 seconds]
FL4SHK has quit [Ping timeout: 256 seconds]
rqou_ is now known as rqou
<edmoore>
well he's outgrowing my statsh of mosfets atm
<edmoore>
a lot of magic smoke
<shapr>
that's my favorite part of hackerspaces
<edmoore>
you can raid other people's stashs?
<edmoore>
gosh i can;t type stash this evening
<shapr>
I used to be a member at the Huntsville, AL hackerspace; real actual rocket scientists doing fun EXTREMELY LOUD things late at night!
<shapr>
one of our crazier rocket scientists mounted a turbo from an rx-7 on a plywood board and used a leaf blower to get the whole contraption started up
<edmoore>
marshall?
<shapr>
nah, redstone arsenal
zkms has joined #yosys
<edmoore>
ha yes i have done the turbo-as-poor-man's-jet-engine thing
<edmoore>
made a rudimentary burner can
<shapr>
one problem, it was after midnight and the hackerspace is in a residential area
<shapr>
second problem, it worked all too well and the plywood base caught fire
<edmoore>
mmm they turn hydrocarbons into noise
<shapr>
I think I was on the board at that time, in case I had all the neighbors yelling at me
<shapr>
in any case*
pie_ has joined #yosys
<edmoore>
:)
<edmoore>
i got a really nice Tek scope for a song afew years ago, for my home lab
<edmoore>
didn't get the logic analyser pod thinking i could livewithout it
<shapr>
I've never used a scope!
<edmoore>
but i think i will regret that soon
<shapr>
someone convince me I need one?
<shapr>
like, why would I want one?
<awygle>
scopes are Good (TM)
<shapr>
ok... so
<shapr>
why?
<edmoore>
i couldn't live without one for electronics
<edmoore>
ideally i;d have two
<shapr>
why so?
<awygle>
:p. i use scopes mostly to troubleshoot signal integrity issues. when the linky no worky it helps me find out why
<edmoore>
they are your eyes
<edmoore>
for me it's just essential. i work with analog signals, i need to see them
<shapr>
not sure I've done any work with analog signals
<shapr>
is that likely to be something I'll need if I dig deeper into FPGAs?
<edmoore>
this amp circuit isn't working: 1) is the signal getting to the input (probe on scope to see), is the amp outputting something (probe the output), is it clipping? (probe the output), are the supply rails oscillating? (probe the rails)
<edmoore>
it also is good for just looking at digital lines
<edmoore>
it has decoders for most common protocols
<edmoore>
it also has a spectrum analyser built in, which is great for RF stuff
<shapr>
I have a bus pirate, I've used that for some things
<edmoore>
i think if you ever actually have to do anything non trivial to do with developing a physical circuit, you will need a scope
<awygle>
shapr: you might, yes, need it for FPGAs, particularly if you are doing board design yourself
<edmoore>
even slowish purely digital circuits, there is always stuff
<edmoore>
catching brownouts
<shapr>
I'm tempted to take an EE class, I work across the street from GaTech, would be easy
<awygle>
i do wish i had a fast scope tho. hard to troubleshoot high speed digital without one.
FL4SHK has joined #yosys
<shapr>
awygle: can I get an FPGA to do that for me?
<edmoore>
or just checking the peripheral is actually doing what you think it is based on a dodgy datasheet with incomplete configuration register descriptions
<shapr>
I just need a fast ADC?
<awygle>
shapr: to do what? troubleshoot SERDES?
<shapr>
edmoore: that's why I tend to buy from adafruit, their libraries just work
<edmoore>
shapr: yeah, it helps. my previous one couldn't see an oscillation supply rail once on an amp i was building
<edmoore>
was oscillating at about 500mhz
<edmoore>
my current one is 1Ghz
<shapr>
that's samples per second?
<shapr>
awygle: I don't know?
<edmoore>
no, bandwidth
<awygle>
you need a fast ADC which means ~5x to 10x the signal rate. which means 5 to 10 GSPS for 1 Gbps signals like 1000BASE-X
<edmoore>
of the front end
<edmoore>
sample rate will be many times higher
<shapr>
ohh
<shapr>
hm
<awygle>
we have been troubleshooting a signal at work with an 8 GHz bandwidth, 20 Gsps scope
<awygle>
(which is awesome even if the software is total garbage)
<shapr>
I guess I need to make friends at GaTech
<edmoore>
it's nyquist theorem, but everyone says 'you must sample at twice the highest freq that you might see', which is nonsense in the real world because that assumes perfect anti-alias filters
<cr1901_modern>
Must be nice to have access to tens of thousands of dollars of equipment :D
<shapr>
I was a guest speaker for their Software Engineering courses
<edmoore>
in reality you want to sample many times higher than the filter cutoff freq
<awygle>
cr1901_modern: it is :D
* cr1901_modern
isn't jealous
* cr1901_modern
is totally jealous
<shapr>
ha
<awygle>
yeah people also get "highest frequency you might see" wrong with digital. it's not the data rate, it's like 5 to 10 times the data rate. edge rates are _fast_.
<cr1901_modern>
If I had access to that equipment I could do cool shit like "try making a PCIe core risk-free"
<awygle>
cr1901_modern: if you make one i'll run the electrical tests for you
<shapr>
awygle: oh that makes sense
* awygle
has "make pcie core in !migen" on his todo list
<shapr>
I'd like to write my own ws2812b/apa102 verilog, I'd probably need a scope for that, yeah?
<awygle>
it would help. a bus pirate might be good enough though if you do the circuit design reasonably well
<cr1901_modern>
awygle: I'll keep that in mind, but it's going to be in migen :). And additionally, if I get past the PHY part I'm home free
<shapr>
would I be able to record signals from a working implementation and compare to what I wrote?
<edmoore>
i'd get a decent multimeter first
<awygle>
cr1901_modern: doesn't litex have one? litepcie?
<edmoore>
but then i'd get a scope
<shapr>
I have a $60 multimeter
<shapr>
is that decent?
<cr1901_modern>
awygle: It's a wrapper over the Xilinx IP
<cr1901_modern>
I meant a FOSS PHY
<cr1901_modern>
which doesn't currently exist AFAIK
<edmoore>
i don't know. there are some gems and a lot og dregs at that price range
<awygle>
oh so it doesn't directly drive the SERDES? bummer.
<edmoore>
or maybe it's fine for electronics but i wouldn't want to dive into a suspect 3-phase system with it
<awygle>
shapr: i have a 50$ Uni-T meter which is fine
<awygle>
i wish there was more documentation trumpeting "you can write a core in migen and include it in a larger verilog/vhdl design"
<shapr>
Has anyone done a comparison of the various tools that output verilog? migen, clash, chisel, etc?
<awygle>
i don't know what all would be involved in that, beyond "copy the generated verilog" i guess, which seems dissatisfying
<cr1901_modern>
>"copy the generated verilog" i guess
<cr1901_modern>
Essentially yes. How would you tell vendor toolchains about it otherwise?
<awygle>
also, and this is definitely a consequence of my background, i find FSMs in Migen incredibly inscrutible compared to verilog
<awygle>
cr1901_modern: well, sure, you need to use the generated verilog, but i want it to be in an integrated way where i don't constantly have stale files in my build
<cr1901_modern>
I'm the exact opposite, though the generated Verilog isn't exactly pleasant
<cr1901_modern>
fusesoc integration that automates the process is somewhere on my bucket list. Eventually. In 25 years.
<cr1901_modern>
at this rate
<awygle>
i also have a kind of grumpy attitude towards new HDLs because we don't have a good toolchain for the HDLs we already have, so it feels like jumping ahead of things
<awygle>
"is verilog bad?" "i don't know because nothing supports anything from the last 15 years"
<awygle>
but errbody can do they own thing :) if migen works for folks they should go for it of course
<shapr>
I would like to try SystemVerilog and all the 'new' toys
<shapr>
does feel like hardware design languages are stuck in the age of the vacuum tube
<awygle>
SV and VHDL-2008 are both super cool, i long to be able to use them someday
<edmoore>
beautifully hand-made?
<shapr>
I like artisanal in very few things
<awygle>
tuned to the temperature of the lab in which they were built :p
<shapr>
awygle: I like to think yosys will put pressure on the big vendors to write some tools that don't suck so much
<shapr>
but I'd rather have open source tools that aren't written by the hardware vendors
<awygle>
yep
* awygle
really needs to read the nextpnr source...
<edmoore>
man tektronix stuff is much too expensive. the logic analyser pod for my scope is about 700USD
<ZipCPU>
awygle: What are you looking for within it?
<edmoore>
it's little more than a breakout for a high-speed connector
<awygle>
ZipCPU: i primarily want to experiment with PnR algorithms. i hope to find that i can write a new placer as a shared library and drop it into a plugins folder and have it Just Work (but i doubt that will happen :p)
<ZipCPU>
Well, it might not "just work", but I'd be happy to help you out along the way if you would like.
<ZipCPU>
(It's supposed to "just work")
<awygle>
ZipCPU: really? the placers are implemented as external shared libraries?
<awygle>
that's what i was guessing was a long shot
Kooda has joined #yosys
marex-cloud has joined #yosys
<ZipCPU>
No, they aren't.
<ZipCPU>
However, they are supposed to be designed so that we can swap them out, and perhaps eventually run a chain of placement algorithms to achieve success.
<awygle>
yeah, that's what i expected
<ZipCPU>
I haven't verified this since the decision to do that was made and vetted.
<awygle>
i wonder if the team would entertain patches to allow loading dll's
<ZipCPU>
Might be fun to ask. Not sure how they'd go about that.
<awygle>
imo it's hard to overstate the value of dynamically loaded plugins for iterative development
<awygle>
i mean they already pick up libtrellis dynamically, right? or is that statically linked?
lutsabound has quit [Quit: Connection closed for inactivity]
<ZipCPU>
Not sure. I know nextpnr has one executable per FPGA class.
<ZipCPU>
I also know the timing libraries were ... a pain to get to build.
<awygle>
lol
<awygle>
in any case, i need to check out the source and blah blah blah
<ZipCPU>
At one time, GCC was requiring well over 4GB of memory just to build them.
<awygle>
but probably not at 1:30pm on a Tuesday
<ZipCPU>
;)
<awygle>
wow really? did you have LTO on?
<ZipCPU>
That wasn't the problem as I understand.
<ZipCPU>
The problem was that we had used a Python script to capture all the internal chip information, and to turn it into fixed tables.
<ZipCPU>
It was just .... too much information for GCC to handle.
<ZipCPU>
Instead, the python script sort of precompiles the values, writes them into a giant char * string, and the compiler just copies that into assembler. Not ideal, I dislike it, but I'm not sure I know a better option.
<edmoore>
ZipCPU: if i may barge in for a sec, in your page on rules for new FPGAers, you/a-contributor mention 'use buildtime paramaters over magic constants'
<edmoore>
do you have a ref you could point me to that expands on that?
<edmoore>
i get the principle, i think, just more like how do you do it nicely in yosys-land
<awygle>
localparam/parameter is better than `define for constants
<awygle>
is how iread that
<ZipCPU>
edmoore: That comes from reading student code. Let me look it up quick to see what I had said.
<ZipCPU>
Hmm ... good question what exactly Marcus Muller was trying to get at. I certainly would rail against magic constants. My own preference it to place any magic constants into parameters if necessary.
<ZipCPU>
But "build-time parameters"? That almost sounds like it needs a special build-time script, since not all synthesizers accept the same build arguments.
<edmoore>
(your site is really helpful btw if i've not mentioned already - thank you)
<edmoore>
yes, i was wondering if there was an equiv of -dTHING
<ZipCPU>
edmoore: Thank you! Feel free to comment or make suggestions as you see fit.
<ZipCPU>
edmoore: With yosys, there is an equivalent of -dTHING
<ZipCPU>
There is also the equivalent of setting parameters inside the yosys script as well.
<edmoore>
i'll pour a coffee and read the docs properly
<edmoore>
ty
<ZipCPU>
Don't waste your time, it's really easy to find.
<ZipCPU>
Run yosys, then type "help read_verilog"
<ZipCPU>
That'll tell you the syntax of the -dTHING that we just discussed
<ZipCPU>
If you want to change a parameter, use chparam.
<ZipCPU>
I can provide examples if you need them.
<ZipCPU>
You can also use the "read -sv" command. That's supposed to replace "read_verilog".
<edmoore>
thanks
<edmoore>
will try now
zino has joined #yosys
<shapr>
edmoore: do you have a twitter account?
<shapr>
edmoore: also, I'll advertise ZipCPU's patreon since he won't ...
<awygle>
shapr: the idea is that if your verilog is controlled by registers (over something like wishbone), you can map those registers into the beaglebone's address space, and write to them from Linux/C
<awygle>
(or something like that. not sure of the details in this particular case.)
* shapr
thinks about that
<ZipCPU>
Gosh, I even do that when the communication has to go through UART. The idea of reading and writing registers is just so fundamental ... it makes things easy.
<shapr>
does that mean I can give the memory inside the FPGA a range of addresses in the the beaglebone's linux memory map?
<ZipCPU>
In my case, no. I'd need to dig into the kernel. In your case, yes, I think you can.
<shapr>
or is that the 256mb of onboard memory that gets addresses in the beaglebone memory map?
<awygle>
it's a very common setup for Verilog modules (even though imo what wishbone calls the "data flow interconnection" is a way better fit for most verilog but never mind)
<ZipCPU>
Doesn't the BBB have an external memory bus running to the FPGA?
<awygle>
shapr: sorry, i don't know much at all about the beaglewire's setup. m_w lurks at least in ##openfpga, possibly here also, maybe ask them
<shapr>
beaglebone itself has 512mb of ram, and the beaglewire cape has its own 256mb of memory
<shapr>
oh, creator of beaglewire, yeah that would be the authoritative source
<ZipCPU>
shapr: No, it's not the quantity of memory that's at interest, but rather the interface to get to the device.
<shapr>
ZipCPU: it does, I think that's the gpmc, I need to read more about that
<ZipCPU>
Yes! I thought I remembered that.
<ZipCPU>
Get that running. if (bus_write) led[7:0] <= bus_data[7:0];
<ZipCPU>
Worry about address decoding later. That alone will get you going.