<azonenberg_work>
felix_: my interpretation is that the goal isn't "bring C to FPGA"
<azonenberg_work>
it's "use your less-highly-paid C programmers to write FPGA code"
<qu1j0t3>
what could possibly go wrong
<azonenberg_work>
Which might actually work often enough to be economically viable as long as you don't mind buying a big FPGA for the inefficient design :p
<qu1j0t3>
what kind of training would be done
<azonenberg_work>
i mean at best it will be like CUDA
<azonenberg_work>
where you have to write specially optimized C for the architecture
<azonenberg_work>
I'm skeptical that it would be a significant speedup over just writing systemverilog
<felix_>
yeah, that's also a target audience. but even if you write the code in c, you really should know how that translates to hardware description
<qu1j0t3>
or teaching people to write some verilog and understand some digital logic
<qu1j0t3>
how expensive would that really be.
<qu1j0t3>
versus how expensive giving no real context to the solution domain.
<sorear>
ftr, there exist OpenCL-to-FPGA tools
<azonenberg_work>
qu1j0t3: I'm old school
<azonenberg_work>
I think that CS programs should start with Boolean algebra
<Bike>
don't they?
<azonenberg_work>
if you want to be a truly rigorous, theory-based program
<Bike>
i had to do k maps and shit
<azonenberg_work>
No i mean, dont start with python or something thien introduce theory later on
<azonenberg_work>
Start from first principles
<azonenberg_work>
Introduce gates at an abstract level, forget timing and all that stuff
<azonenberg_work>
Demonstrate how to build some basic adders and stuff
<Bike>
oh. then nobody would take the classes.
<Bike>
i guess that beats oversaturation.
<azonenberg_work>
Work your way up to machine language for like a 4-bit CPU
<sorear>
i mean the advantage of C over SystemVerilog is that C has a spec and there's wide agreement about how to intepret it and what the necessary features to support are /s
<azonenberg_work>
Then introduce an assembly language for that
<zkms>
tbh i find writing verilog less stressful than writing C
<qu1j0t3>
azonenberg_work: Obviously I'm a bit old school as well, enough to be suspicious of this shortcut
<azonenberg_work>
after a homework using that, switch to a real asm for something like MIPS or ARM
<qu1j0t3>
zkms: ikr?
<azonenberg_work>
Then introduce C as a convenient abstraction on top of that
* sorear
*did* start with gates, and was very confused moving to verilog because the synthesizability rules are … non-obvious
<sorear>
"this is clearly a simulation language, not a HDL"
<qu1j0t3>
sorear: I agree
<azonenberg_work>
And toolchain dependent
<qu1j0t3>
sorear: i think this is a big issue for beginners
<zkms>
(this is not an endorsement of verilog >_>)
<azonenberg_work>
even ISE to vivado adds lots of new functionality like systemverilog
<azonenberg_work>
while also removing things i had really come to depend on
<azonenberg_work>
Like $display and $finish at synthesis time
<zkms>
i want to learn SV some day...
<azonenberg_work>
(there is NO standard way to print a message and abort, a la C's #error, in systemverilog at synthesis/elaboration time)
<sorear>
puzzle: is it possible to make a HDL that has well-defined semantics and doesn't exist at right angles to the entire ecosystem
<qu1j0t3>
:)
<azonenberg_work>
Yosys and ISE support $display with static arguments as "print to stdout of synthesis"
<azonenberg_work>
And $finish as "abort synthesis with error"
<azonenberg_work>
So you can have a module that, say, refuses to synthesize with a nonsensical configuration
* sorear
wonders if the reg message_here[(condition ? 1 : -1) : 0] trick works in verilog
<azonenberg_work>
Vivado just ignores them
<azonenberg_work>
sorear: there is a hack where you put a generate block
<azonenberg_work>
and instantiate a "module foo_should_never_be_less_than_bar_so_throw_error();"
<azonenberg_work>
But there is not a standardized way to do this
<azonenberg_work>
there is also not even a workaround i've found that lets you print informational messages or warnings at synthesis time
<rqou>
i thought the usual way was "choke me" :P
<azonenberg_work>
rqou: that doesnt provide context
<azonenberg_work>
unless you have comments around it
<rqou>
works for autocrap :P
<azonenberg_work>
For example, I have a PLL IP that calculates multiplier and divider values at synthesis time
<azonenberg_work>
rqou: yes but those errors are testing if something works, not intended to be read by a human to debug their code
<azonenberg_work>
anyway, in ISE it correctly prints out a log showing the VCO frequency etc
<azonenberg_work>
In vivado it just silently works
<sorear>
no construct sufficiently awful that every toolchain will warn about it, but not actually illegal? :p
<azonenberg_work>
sorear: the problem is that the warning is lost
<azonenberg_work>
in the sea of 30000 warnings thrown by innocuous things
<azonenberg_work>
Thats the other problem
<azonenberg_work>
fpga tools universally warn about harmless things AND their own IP cores
<azonenberg_work>
you cannot have a warning-free design using any xilinx IP core
<azonenberg_work>
it's not possible
<sorear>
sheesh
<sorear>
gcc has had -isystem since approximately forever?
<azonenberg_work>
you get hundreds of warnings just for dropping in a chipscope instance
<azonenberg_work>
you get warnings for things that in the software world would just be considered optimizations
<azonenberg_work>
ISE would warn about some constant folding :D
<azonenberg_work>
in the software world, at least on serious projects, zero warnings is an achievable goal most serious projects strive for
<azonenberg_work>
in the fpga world its nearly impossilbe unless you declare some warnings spam and just grep them out of the synthesis log
<jn__>
no -Wno-* equivalent in fpga toolchains?
<azonenberg_work>
no good one i found last time i looked
<azonenberg_work>
you can probably do tcl stuff to filter the output maybe? ise had some weird xml filter spec
<azonenberg_work>
i just ran grep -v to postprocess the logs :p
mumptai has quit [Remote host closed the connection]
pie_ has joined ##openfpga
<sorear>
hmm, trying to do tdd-lite with the riscv conformance tests is not going to work, because we need a fair amount of ISA support to run the harness
<azonenberg_work>
riscv-formal?
<azonenberg_work>
(how simple is your core?)
<sorear>
pretty simple
<sorear>
i guess I could do formal with a bunch of hack assumes
luvpon has quit [Ping timeout: 250 seconds]
azonenberg_work has quit [Ping timeout: 268 seconds]
pie__ has joined ##openfpga
pie_ has quit [Ping timeout: 268 seconds]
zkms has quit [Quit: reboot]
zkms has joined ##openfpga
jevinski_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
* sorear
not quite sure how to make best use of resets
<cr1901_modern>
Use sync resets to avoid metastability issues?
<sorear>
I have what I think is a reasonable understanding of the physics of resets, but not of "how should resets work in an API of a core that wants to be useful"
<cr1901_modern>
The way Migen does it is "every reg you create is reset" unless you explicity put a signal in a clock domain which doesn't have a reset (or explicitly say "this reg does not respond to reset")
<cr1901_modern>
When you have your core working, you can go back and start removing resets from regs whose initial value you think doesn't matter
<cr1901_modern>
if your core fails riscv-formal without the resets, add some resets back in :)
jevinskie has joined ##openfpga
jevinskie has quit [Ping timeout: 250 seconds]
<sorear>
so "initial forever" is the same as "always" except non-synthesizable
<cr1901_modern>
I've never used forever
balrog has quit [Quit: Bye]
balrog has joined ##openfpga
SpaceCoaster_ has joined ##openfpga
[X-Scale] has joined ##openfpga
SpaceCoaster has quit [Read error: Connection reset by peer]
X-Scale has quit [Ping timeout: 252 seconds]
[X-Scale] is now known as X-Scale
unixb0y has quit [Ping timeout: 252 seconds]
unixb0y has joined ##openfpga
<rqou>
btw, i figured out why silego exists / who is (was) keeping them alive
<rqou>
at least before getting acquired
<rqou>
surprise surprise, it's apple
<zkms>
:3
<reportingsjr>
I was about to say, did apple get silego as part of the dialog deal?
<rqou>
if you look at (at least the ones that are several years old) the leaked apple macbook schematics, it's full of silego glue
<zkms>
cute :3
<rqou>
some of them are even drawn with a small representation of the circuit inside
<galv[m]>
I'm about to reimage a laptop with linux. Any suggestions on whether I should do Ubuntu 16.04 or Ubuntu 18.04? My understanding is that most OSS hardware people have been using Ubuntu 16.04 lately.
<rqou>
debian sid or arch linux :P
<zkms>
arch linux >_>;
<galv[m]>
I am moving away from Debian sid. I got tired of breaking my graphics display when installing Nvidia's drivers. Ubuntu just works, meanwhile, in my experience at jobs.
<rqou>
huh, i've had more or less exactly the opposite experience
<rqou>
oh wtf macbooks have a hidden smc debug interface somewhere on the usb port
<cyrozap>
rqou: I thought the Apple-Silego relationship was already known?
<rqou>
was it?
<rqou>
i didn't know
<rqou>
i suspected it though
<cyrozap>
I thought it was even mentioned in this channel...
<rqou>
given that a relatively obscure fabless company has _so many_ parts
<rqou>
and has stuck around
<sorear>
I knew about Apple-Lattice
lovepon has joined ##openfpga
<cyrozap>
galv[m]: > Nvidia's drivers
<rqou>
i wonder how many companies apple is single-handedly propping up?
<cyrozap>
galv[m]: No wonder you had trouble with Debian :P
<rqou>
from another channel: <rqou> it's pretty disappointing how apple "strategy" squanders their engineering talent
<galv[m]>
cyrozap: Yep. It was educational, though. Unfortunately, I need to nvidia's drivers for my GPU programming work, so I will be going with Ubuntu. The nerd inside me really wants to do Arch for fun, though.
<cyrozap>
galv[m]: Ah, yeah, if it's for work that makes sense.
_whitelogger has joined ##openfpga
jevinskie has joined ##openfpga
<whitequark>
sorear: ok so wanna know what NOT to do in your TAP?
<whitequark>
MIPS EJTAG CONTROL register is something you need to read when you start a probe.
<whitequark>
but you can't read it and not go through Update-DR.
<whitequark>
so you have to first shift it *out* and then shift it *back in*
<whitequark>
to avoid just utterly messing up its state.
<whitequark>
*but* it has a bit that acknowledges a reset that is not idempotent...
<whitequark>
oh nvm, it *is* idempotent, it's just really confusingly written
<whitequark>
ok then do that I guess
<sorear>
nice
<whitequark>
do not write documentation like MIPS does it.
<whitequark>
or i will find you.
<sorear>
*makes note: do not write documentation* gotcha
<sorear>
how do people avoid name collisions between modules. there's no multi-level namespace is there?
<cr1901_modern>
Don't think so :)
<cr1901_modern>
actually... it's weird. If you're doing simulation, tasks like $display and $dumpvars will allow you to use "full.path.to.signal" notation
<cr1901_modern>
but I don't think it's used anywhere else
Bike has quit [Quit: Lost terminal]
<sorear>
that's called a hierarchical name (§12.5 in 1364-2005) and I think they're allowed everywhere except…constexprs
<sorear>
i can do immed <= riscv.get_utype_imm(insn); but I can't do reg [XLEN-1:0] regs[riscv.n_regs]
<sorear>
contrived example
<sorear>
(haven't tested either, from reading the spec)
<cr1901_modern>
is get_utype_imm a function/task?
<sorear>
function
<sorear>
tasks don't return values
<cr1901_modern>
I also think tasks can call other tasks but functions can't call other functions
<cr1901_modern>
err s/functions/tasks/ that last one
<sorear>
right, functions can't call tasks
<cr1901_modern>
Could've sworn tasks could return output...
<sorear>
tasks can have out parameters
<sorear>
it's very like pascal or sql
<sorear>
despite the rest of verilog trying to pretend to be C
ZombieChicken has quit [Ping timeout: 256 seconds]
jevinskie has joined ##openfpga
genii has joined ##openfpga
Hamilton has joined ##openfpga
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jevinskie has joined ##openfpga
jevinskie has quit [Ping timeout: 244 seconds]
<sorear>
it seems potentially nontrivial to have a register of parameterized possibly-zero size. can't do reg [len-1:0] whatever; because reg [-1:0] defines a 2-bit register
emeb has joined ##openfpga
<fseidel>
wait, [-1:0] is legal?
<sorear>
bits can be numbered increasing or decreasing, and individual bit numbers can be negative
<fseidel>
5 years of writing verilog and I never realized that, huh
<pie_>
...negative?
<qu1j0t3>
only labels pie_
<pie_>
oh is that like, "start counting from the /other/ end"?
<sensille>
just from bit -1 to 0
<sorear>
reg [31:0] is a normal people register, reg [0:31] is an IBM register
<fseidel>
or motorola :)
<fseidel>
well, that's a horrible verilog trick I can now show to students during recitation :-D
<sorear>
i haven't tested it, just looking at the examples under §4.3.1 Specifying vectors
<fseidel>
trying it with VCS, if that works I'll run it through DC
<fseidel>
VCS is happy with it, jesus christ
<fseidel>
and so is DC o.O
<sorear>
DC, fancy
<fseidel>
DC isn't happy with a lot of SV things like struct initializers
<fseidel>
and even chokes on some more esoteric normal verilog things
<fseidel>
so I'm kind of shocked it's okay with negative indexing
<pie_>
this is you [31:0], this is you on ______ [-1:0]. ______. not even once.
<fseidel>
yeah, DC is fancy and all until it decides to randomly crash during a 4 hour synthesis run for a project due the same day...
<qu1j0t3>
pie_: don't freak out
<qu1j0t3>
pie_: #define TRUE 0
* qu1j0t3
wipes hands that should keep him busy
<sensille>
good to check if everyone uses the macros
Bob_Dole has joined ##openfpga
<azonenberg_work>
fseidel: meanwhile, DC and VCS like a lot of SV stuff vivado doesn't
<azonenberg_work>
Like arrays of interfaces
<azonenberg_work>
And even some union stuff
<azonenberg_work>
This is a nightmare when fpga prototyping asic code...
<fseidel>
yeah, happened to a friend of mine who was using VCS to simulate stuff that needed to be loaded onto a Xilinx FPGA
<fseidel>
VCS was happy, Vivado just straight up crashed
<fseidel>
turned out to be an issue with unions
<fseidel>
I've never seen a tool crash more than Vivado
<fseidel>
although I've managed to kill segfault quartus 14 by trying to slice an enum that didn't have values explicityl assigned to the labels
<fseidel>
is this a good thing to do? no. it also should generate a warning/error and not segfault the router :-P
<fseidel>
qu1j0t3: you forgot `default_nettype real
<pie_>
heh, thats great: "Three years into the Kepler mission, two of the observatory’s four reaction wheels, the devices that allowed it to maneuver in space, failed. Engineers couldn’t repair them, but they did come up with a clever way to keep Kepler going: When the light of the sun pressed against the space observatory’s solar panels, engineers programmed the two remaining wheels to press back. That interaction allowed them to point K
<pie_>
epler where they wanted."
<qu1j0t3>
science 1 - entropy 0
<pie_>
man wtf 2009 was almost 10 years ago.
<jn__>
tfw getting old
<pie_>
there was a space probe i saw something about on the discovery channel way back when it didnt suck, something about sending a probe to burrow the ice on europa, might have still been speculative bs :D
<pie_>
did anything ever come of that
Hamilton has quit [Quit: Leaving]
<qu1j0t3>
there was certainly a movie, named iirc EUROPA
genii has quit [Read error: Connection reset by peer]
<azonenberg_work>
(13:03:10) fseidel: I've never seen a tool crash more than Vivado
<azonenberg_work>
you clearly have not used ISE much
<azonenberg_work>
i have crashed vivado reproducibly many times
<azonenberg_work>
But not nearly as frequently as ISE core dumping on me
feuerrot has quit [Ping timeout: 264 seconds]
<Bob_Dole>
ice40s have onbooard flash for store configuration don't they? how useful is it/is it supported by icestorm?
feuerrot has joined ##openfpga
<daveshah>
Bob_Dole: no, they only have one time programmable NVCM
<daveshah>
It's not supported in icestorm because of the potential cost in lost parts and lack of interest to add support
<Bob_Dole>
Oh I thought it was just flash that got a fuse bit blown out at the end of writing
<Bob_Dole>
not an actual prom
Miyu has quit [Ping timeout: 246 seconds]
mumptai has quit [Quit: Verlassend]
<fseidel>
TIL: DC isn't okay with [9], only [8:0] or [0:8]
Dolu has quit [Ping timeout: 250 seconds]
jevinskie has joined ##openfpga
<mithro>
azonenberg_work: Yes, ISE is much more crashy then vivado
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]