<azonenberg>
cr1901: note what's happening to e.g. \shreg.shreg
<cr1901>
oh you're trying to fix the shift reg problem?
<azonenberg>
No'
<azonenberg>
No*
<azonenberg>
I'm trying to use Yosys to convert bitstreams back to RTLIL cells
<azonenberg>
and then extract coarse-grained abstractions from the RTLIL
<cr1901>
If !1'h1... welp yea, that's never gonna execute
<cr1901>
azonenberg: So, Blinky-ir.v is the output of what you're trying to do? And
<azonenberg>
Yes
<cr1901>
\shreg.shreg is an indication that yosys failed to infer the correct GP4 primitive?
<azonenberg>
No no
<azonenberg>
i'm not synthesizing to the GP4 tech lib
<azonenberg>
i'm doing the opposite
<azonenberg>
i'm importing a synthesized, techmapped netlist, like i'd feed to gp4par (or i'd get from a bitstream dumping tool)
<azonenberg>
and trying to convert it back to behavioral verilog
<azonenberg>
So the first step is to techmap with cells_sim.v
specing has quit [Read error: Connection reset by peer]
<azonenberg>
and now i want to optimize out the cells whose resets aren't being used into cells without resets
<cr1901>
Ahhh, so the !1'h1 is "useless" and yosys should've recognized that, but didn't
<balrog>
why does stuff like if (!1'h1) ... appear?
<azonenberg>
Good question
<balrog>
because that's what's in the bitstream?
<azonenberg>
balrog: no
<azonenberg>
probably this is how yosys handles a DFFSR with SR hard-coded to 1 in write_verilog
<cr1901>
Probably some edge case in verilog spec?
<azonenberg>
The question is what optimization path, if any, folds DFFSR-with-reset-always-inactive to DFF
<azonenberg>
and if not, i'll write one
<cr1901>
azonenberg: What you're asking makes sense, but I don't have experience with this, only from RTLIL to GP4
<azonenberg>
Yeah i know
<azonenberg>
This is research for a con talk next month
<cr1901>
Pass would look something like "if net attached to reset port of _DFF_PN0 == Constant one, replace _DFF_PN0 with DFF" though
<azonenberg>
trying to see how far i can get
<azonenberg>
Yeah
<azonenberg>
you know
<azonenberg>
i wonder if i could do that with the techmap command
<azonenberg>
i dont think so
<azonenberg>
theres no way to tell the input is a 1 at that level
<cr1901>
why not?
<azonenberg>
techmap works on cells
<azonenberg>
it sees attributes and parameters etc
<azonenberg>
but it can't map to one thing or another based on *port* connections
<openfpga-github>
[yosys] azonenberg pushed 1 new commit to master: https://git.io/v7r47
<openfpga-github>
yosys/master 40543d8 Andrew Zonenberg: Improved cells_sim_digital model for GP_COUNT8
<coino>
wonder if this could be solved with AI ML
<coino>
train it with verilog and netlists
<coino>
and then have it do magic
<rqou>
you don't need ML
<rqou>
circuits are far more structured
<azonenberg>
Ok so now that i've done a quick PoC of desynthesis
<azonenberg>
from a synthesized netlist
<azonenberg>
i think i'm gonna shift gears a bit
<rqou>
alright, time for me to stop playing with dolphin+radv
<rqou>
i think i've had enough gpu hangs for today
<rqou>
time to get back to work
<coino>
what is radv
<rqou>
the open-source amd radeon vulkan driver
<cr1901>
azonenberg: Why do you have a drawer made of steak?
<azonenberg>
cr1901: it was the name of my old consulting company circa 2009
<rqou>
at least on my kernel radv seems to hang the gpu a lot whenever something "global-ish" happens
<rqou>
such as exiting
<azonenberg>
and it was steak *in* a drawer
<azonenberg>
or, nearly so
<azonenberg>
due to a misunderstanding while helping an officemate put away groceries in the minifridge
<cr1901>
I don't think you could really cook a steak in a drawer
<azonenberg>
the steak almost went in a desk drawer
<azonenberg>
somehow that became the name of the company
<rqou>
also, ugh why is debian still on kernel 4.11?
<rqou>
azonenberg: there you go, something that i want bleeding-edge for :P
<azonenberg>
rqou: whats wrong with 4.11?
<rqou>
amdgpu+radv hangs the entire gpu?
<azonenberg>
honestly i'd be fine with 2.6 for most of my stuff if i still had security patches :p
<azonenberg>
and i use the nvidia blobs
<azonenberg>
so, no problem there
<rqou>
recently i've been getting xorg crashes with the blob
<rqou>
if only linux could get an up-to-date drm+mesa+xorg and stable everything else
<coino>
is simulink the only viable diagram to hdl tool
<azonenberg>
coino: no idea, i've never looked into it
<azonenberg>
i'm the opposite, i'm trying to figure out how to do PCBs in HDL
<azonenberg>
so i don't have to ever touch a schematic again :p
<coino>
why
<azonenberg>
just import a synthesized verilog design into a pcb layout tool
<azonenberg>
schematics are not version control friendly
<coino>
sure
<azonenberg>
they're almost impossible to meaningfully diff, or have multiple engineers working on at once
<azonenberg>
you can't do parameterized IP cores
<coino>
i'd wish hdl wizards did more than boilerplate
<azonenberg>
i want to be able to design a SMPS based on a given chip once, then request target voltages/current and have it compute all of the passive values for me
<coino>
i just want to put some blocks together and have the tools figure the details
<azonenberg>
generate a BOM
<azonenberg>
and export pre-verified geometry to the layout tool as a "hard IP core"
<rqou>
<shill>ni labview is also a diagram to hdl tool</shill>
<rqou>
azonenberg: is that possible in general? i think you can only really do that with "simple" SMPS designs
<coino>
what is shill
<rqou>
e.g. not an intel Vcore regulator with multiple phases and very large peak/average difference
<rqou>
oh, i briefly worked at NI, so i have to make a disclaimer :P
<coino>
discliamer of what
<coino>
never used lv
<coino>
because you endorse it
<rqou>
a disclaimer that i'm not being forced to encourage use of labview
<coino>
cypress is almost the perfect tool
<coino>
psoc creator
* cyrozap
is triggered
<coino>
but only for the built in modules not custom ones
<rqou>
ugh, finally succeeded in getting most/all of my mobile apps signed in again on my new device
<rqou>
why does everybody insist on reinventing shitty 2FA schemes and then forcing people into them?
<rqou>
if your 2fa is good, i would have enabled it
<rqou>
if your 2fa sucks, i probably didn't enable it for a reason
<pie_>
rqou, ive been spending all day NOT porting about 20 lines of code over to ANTLR
<cyrozap>
PSoC Creator is great if you don't care about version control and don't mind using generated code all over the place.
<cyrozap>
Cypress's idea of version control is a directory of numbered Zip files, each containing a complete copy of the project folder.
<coino>
cyrozap, yep
<coino>
vc isn't something I'm concerned with atm
<cyrozap>
Oh, and then there's the whole Windows-only thing :P
<coino>
i run a vm on mac
<azonenberg>
coino: schematics may be easier for one person tinkering but as soon as you try to do anything serious they're more trouble than they're worth
<coino>
maybe, never done any
<azonenberg>
coino: and how much HDL have you done?
<azonenberg>
rqou: re SMPS IP, i'm not trying to have it design an arbitrary SMPS
<coino>
barely
<azonenberg>
rqou: i'm trying to say "give me an LTC3374 based design that has 2 phases/4A on 1.0V, 1 phase/2A on 1.8V, 1 phase/1A on 2.5V, 1 phase/1A on 3.3V"
<azonenberg>
and just pick components
<azonenberg>
or even just "give me an FT232H based USB-JTAG circuit"
<rqou>
including figuring out stuff like loop filters?
wpwrak has quit [Ping timeout: 240 seconds]
<azonenberg>
pretty sure the 3374 doesn't normally need compensation, but you could add it to the core if desired
<azonenberg>
My point is, HDL based IP can be arbitrarily simple or complex
<azonenberg>
any code reuse beats none
<rqou>
sure
<azonenberg>
Any design-time DRCing you can automate is better than none
<azonenberg>
The dream is a type-safe DRC that lets you ensure a SPIBus isn't hooked up to an I2CBus
<azonenberg>
or a 3.3V LVCMOS GPIO isn't hooked up to a 1.8V input
<rqou>
and isn't powered by highlighters? :P :P
<azonenberg>
That too
<azonenberg>
Would also be nice if you could do something like
<rqou>
not e.g. one where you have to call the FAE in to make measurements on your board to tell you what to do next
<azonenberg>
then have that turn into the proper netclasses etc
<azonenberg>
rqou: lol
<azonenberg>
of course
<coino>
DRC?
<azonenberg>
But what percentage of SMPSes don't need that?
<rqou>
basically all the things i'll build for myself don't need that
<azonenberg>
coino: design rule check
<azonenberg>
rqou: exactly
<azonenberg>
and you can still explicitly create chips and passives and hook them up
<azonenberg>
and do hand layout of the smps
<azonenberg>
if you need that level of control
<azonenberg>
The idea is to make the other 99% of designs take less effort to build and be more likely to be right the first time around
<coino>
I just want to proto ideas quickly
<coino>
and do the least fiddling possible
<coino>
exploring what the psoc chip can do
wpwrak has joined ##openfpga
<cr1901>
FAE?
<coino>
?
<azonenberg>
cr1901: field applications engineer
<coino>
oo
<coino>
sounds military
<pointfree>
The #PSoC channel has been moved to ##PSoC come join if you're interested in psoc tools discussions of any kind! Welcome!
<azonenberg>
rqou: Thoughts on creating a code generator for C++ and/or Rust (ideally, target both) bitstream serialization/deserialization code?
<azonenberg>
write a meta-description of the format in YAML, have it generate code for each primitive from that
<azonenberg>
or something along those lines
<azonenberg>
After the con, it's a lower priority, but seems like it'll be good to have down the road
<rqou>
back when i was in seattle you told me you hated data-driven designs because they were slow
<azonenberg>
This isn't data driven
<rqou>
ooooh
<rqou>
i see
<rqou>
hmm
<azonenberg>
this is closer to a sql ORM
<azonenberg>
you create a schema and it generates code to map to/from the serailized format
<rqou>
i'll think about it
<azonenberg>
but instead of something like protobufs the goal is to ser/des a specific binary packed format
<azonenberg>
to a C++ data structure
<azonenberg>
If we could make it also map to/from verilog attributes and such that would be even better
<rqou>
i'm definitely not doing a general-purpose one again any time soon :P
<azonenberg>
There's a lot of boilerplate there too
<azonenberg>
Yeah i'm just thinking how much time i've spent writing greenpak bitstream packing/unpacking code
<azonenberg>
that really should be generated IMO
<rqou>
(i've done multiple "general purpose" ser/des generators there were all slightly shitty and not in fact general purpose)
<azonenberg>
Yes, this is specifically intended for bitstream stuff
<azonenberg>
Basic flow: Create bitstream format template
<azonenberg>
Generate ser/des class for each primitive
<rqou>
for bonus points i also have one that did codegen for C and was data-driven for JS
<azonenberg>
Either use these directly, or add application specific logic to a derived class
<rqou>
it sucked because of just how verbose it was
<azonenberg>
yeah well look at how verbose the greenpak code is with all the conditionals to map to/from verilog attributes and bitstream stuff
<azonenberg>
i feel like this is generatable
<azonenberg>
I'm gonna file a ticket on openfpga and mark as "to discuss"
<rqou>
the only thing i'm concerned about is the places where you need/want "some random bit of code"
<rqou>
e.g. xc2 has some "use the zia look up table" code
<azonenberg>
So my thought was that this would be done in the derived class
<rqou>
and miscellaneous stuff to match together IOBs and FFs
<azonenberg>
the serdes would just pick out a "mux selector" value
<azonenberg>
and the derived class then adds the logic to hook up the routing based on that
<azonenberg>
But we can discuss the arch more down the road
<azonenberg>
i just think it'd make, long term, new device support etc a lot easier
<rqou>
huh, so you're focusing on _just the bits_
<azonenberg>
Yes
<azonenberg>
Just bit twiddling
<rqou>
yeah, xc2 has a bunch of error-prone code for that
<azonenberg>
Plan is, generator outputs a serdes class
<rqou>
in fact, it actually has two copies :P
<rqou>
(one for jed, one for crbit)
<azonenberg>
you then create a class that inherits from that and adds code to actually do stuff
<rqou>
both of which just have magic numbers everywhere
<azonenberg>
So tentative consensus at this point: we need to do it, but we're not sure how or what "it" is yet?
<rqou>
i don't think it'll be possible to express all of the contents of xc2bit in yaml
<rqou>
that would just turn into the inner-platform effect
<azonenberg>
Yes, you don't
<azonenberg>
You express the serdes only
<openfpga-github>
[openfpga] azonenberg opened issue #107: Try to come up with a code generation tool for serializing/deserializing bitstream data https://git.io/v7raI
<azonenberg>
unpack the fields, assign names to enumerated constants, etc
<rqou>
so e.g. the code here:
<rqou>
// inmod
<rqou>
fuse_array.set((x + d * 1) as usize, y + 0, inmod.1);
<rqou>
fuse_array.set((x + d * 0) as usize, y + 0, inmod.0);
<rqou>
let inmod = self.ibuf_mode.encode();
<rqou>
// dg
<rqou>
fuse_array.set((x + d * 4) as usize, y + 0, self.uses_data_gate);
<rqou>
// oe
<rqou>
let oe = self.obuf_mode.encode();
<rqou>
fuse_array.set((x + d * 3) as usize, y + 1, oe.0);
<rqou>
fuse_array.set((x + d * 4) as usize, y + 1, oe.1);
<rqou>
fuse_array.set((x + d * 5) as usize, y + 1, oe.2);
<rqou>
fuse_array.set((x + d * 6) as usize, y + 1, oe.3);
<rqou>
// inz
<rqou>
let inz = self.zia_mode.encode();
<rqou>
fuse_array.set((x + d * 7) as usize, y + 1, inz.0);
<rqou>
fuse_array.set((x + d * 8) as usize, y + 1, inz.1);
<rqou>
// tm
<rqou>
fuse_array.set((x + d * 2) as usize, y + 2, self.termination_enabled);
<rqou>
// slw
<rqou>
fuse_array.set((x + d * 3) as usize, y + 2, !self.slew_is_fast);
<azonenberg>
so things like uses_data_gate could be handled by the serdes class directly
<rqou>
// regcom
<rqou>
fuse_array.set((x + d * 8) as usize, y + 2, !self.obuf_uses_ff);
<rqou>
which is totally obvious how it works :P
<azonenberg>
or regcom
<rqou>
basically all of these could be
<azonenberg>
The others i'd need ot look at a little bit more
<azonenberg>
as far as what the encode stuff is
<azonenberg>
but yeah, the idea is to make as much of the generic boilerplate as we can
<rqou>
encode is basically just a switch
<azonenberg>
ah ok then yeah
<azonenberg>
Also look at code like this
<rqou>
i definitely haven't made any errors at all when writing all of the (x + d * 8) and stuff
<rqou>
actually i just realized i have four copies of the code
<rqou>
crbit save, crbit load, jed save, jed load
<azonenberg>
basically define a mapping from verilog parameters to member variables, default values for unspec'd parameters, etc
<azonenberg>
Let's try and not write too much more parser code for the time being
<rqou>
it's not like i ever made them mismatch or anything! :P :P
<azonenberg>
with a view of eventually doing a generator for all of that
<rqou>
i don't know about going all the way to verilog though
<azonenberg>
as far as jed goes, my thought is to have a JED reader/writer that just turns a jed into a bitstream
<azonenberg>
then the generator would go bitstream to object model
<azonenberg>
where "bitstream" means literally a bool[]
<rqou>
for xc2 there's definitely intermediate logic between the logical bitstream and the jed
<azonenberg>
Yeah what i meant was
<azonenberg>
you have a jed parser that gives you a bool[]
<azonenberg>
then the generator would parse the bool[] into the object model
<rqou>
so right now the jed parser gives a bool[] but the crbit parser gives a bool[][]
<rqou>
and then there are two code paths
<rqou>
so twice as many potential errors
<azonenberg>
Lol
<azonenberg>
Yeah
<azonenberg>
This has to all get refactored
<rqou>
the problem is that if you went from jed to bool[] to bool[][] there is still a potential for the same errors
<azonenberg>
i wont have time to do this until i get my urgent research stuff out of the way
<azonenberg>
But try to keep this in mind down the road
<rqou>
yeah i see
<azonenberg>
From my perspective the more boilerplate we can get rid of the better
<azonenberg>
and this boilerplate is clearly present in both C++ and rust
<rqou>
unfortunately the way i've written the code so far there isn't a 100% match between technology-specific cells in verilog and bitstream objects
<azonenberg>
Yes, there's some mismatching in greenpak too
<rqou>
e.g. the register in the macrocell can turn into any of a FDCP/LDCP/FTCP/FDCPE
<azonenberg>
We should have a more serious architectural discussion as far as cleanup goes in a bit once i'm no longer racing for a con deadline
<azonenberg>
So, the way i handle this in greenpak is
<azonenberg>
i have a 1:1 mapping between C++ objects and bitstream objects
<azonenberg>
then a N:1 mapping between verilog objects and C++ objects
<rqou>
yeah i have that too
<azonenberg>
so during the verilog-to-object-model transformation you have to check the type of the module
<azonenberg>
error if it's invalid
<azonenberg>
then if valid, use one of several mappings of port/parameter names to internal object model
<rqou>
i don't want to express that in a descriptive language though
<azonenberg>
i was thinknig of juist having a YAML array of
<azonenberg>
bitstream object:
<azonenberg>
m_resetPolarity: hdl.SRVAL
<azonenberg>
hdl primitive B:
<azonenberg>
m_resetPolarity: 1
<azonenberg>
hdl primitive A:
<azonenberg>
something like that
<rqou>
hmm
<rqou>
but my PAR will _still_ have special cases
<azonenberg>
Yes, we always will
<rqou>
because right now there's a hack thing to figure out "when a signal comes in from the zia, which row did it come from?"
<azonenberg>
So we have the generator produce 98% of the boilerplate then have the derived class call the generated code to parse all but that one odd field
<rqou>
which creates a "ZIA DUMMY BUF" object
<azonenberg>
and then do the last bit in regular code
<azonenberg>
I feel like we will probably both have to refactor our code
<azonenberg>
but this will produce a better, more maintainable codebase long term
<rqou>
yeah, right now there's a giant clusterf*ck in my code called "output.rs"
<azonenberg>
gives the performance of custom code and the maintainability of data driven
<rqou>
it's the giant thousand-line function i showed you at defcon
<azonenberg>
and ideally, we can reuse the parser generator for all of our future device support
<rqou>
hmm do you know how icestorm/icebox works?
<rqou>
i do recall clifford saying not to use that though
<rqou>
and to just dump icebox's data model out into files and then using that to build a "real" data model
<azonenberg>
lolol
<azonenberg>
no i dont
<azonenberg>
pointfree: So why are you making a separate channel?
<azonenberg>
is that for non-RE stuff?
<azonenberg>
because i'd still like to keep toolchain chatter in here
<azonenberg>
lol of course whitequark is gonna say rust :p
<pointfree>
azonenberg: For toolchain usage, non-toolchain stuff, non-yosys stuff, non-cpld-psoc stuff, etc. There was already general PSoC chatter in #PSoC. It's channel operator was absent. I wanted to set a topic and the freenode ircops said it should follow the "##" naming scheme and be related to FOSS development to be on-topic for freenode.
<azonenberg>
Ah, ok that makes sense
<azonenberg>
Just making sure you weren't moving the toolchain development stuff there too
<azonenberg>
a dedicated channel for research makes sense
<azonenberg>
for usage*
<azonenberg>
gaah
<pointfree>
azonenberg: I still think it's best to keep yosys-PSoC stuff in this larger channel for more exposure but with organization into a separate channel perhaps there will be the feeling of more room to expand into stuff like USB drivers, etc, etc which is probably not interesting to people here. In practice there will likely be more Cypress PSoC Creator discussion as well.
<azonenberg>
Yeah makes sense
digshadow has joined ##openfpga
<cr1901>
azonenberg: I like Rust far more than C++; I don't think we should be rewriting ##openfpga (or making its subcomponents written in it) just to use it.
<azonenberg>
cr1901: yes, and i dont want to redo everything in rust either
<coino>
rusty
<azonenberg>
Lol
<rqou>
there's a fun project called corrode
<rqou>
it translates c into unsafe rust
<whitequark>
no
<whitequark>
just... no
<whitequark>
azonenberg: i do think the parts that load and save bitstream can be redone in rust alone
<whitequark>
firefox uses a binding generator to interface with c++
<whitequark>
in mozilla
<whitequark>
for a very similar job, i think parsing mp4 or mkv?
<rqou>
oh, i thought we were just making jokes about the word rust
<rqou>
yeah, mozilla was doing it for an mp4 parser
<rqou>
unfortunately, they failed their wishful goal of 0 panics
<rqou>
thanks to people being lame and still using 32-bit
<coino>
Rust.js
<rqou>
works
<cr1901>
Is it a "both Rust and C++ agree to use the C ABI to talk to each other" binding generator?
<rqou>
pretty much
<rqou>
anybody want to be evil and try to generate c++ vtables from rust?
<cr1901>
How would you do that in the first place?
<rqou>
vtables are easy
<rqou>
the rest of c++ is horrible though
<rqou>
hence why COM was invented
<cr1901>
I mean, I don't know how to make Rust "aware" of vtables without modifying rustc to generate the proper code for them (or is that what you meant?)
<rqou>
you can just construct data that matches the relevant C++ abi's idea of what a vtable should look like
<rqou>
e.g. just construct an array of function pointers, where the first is a "destructor" and the rest are virtual methods in order
<rqou>
i believe this is how MSVC constructs vtables
<rqou>
iirc gcc somehow has it in a different order
<cr1901>
Well... I... huh... I guess that would work. Rust would need to know how to pass in input args/stack alignment/etc in C++ (Itanium ABI?)
<rqou>
ooh yeah, you do need to teach rustc about the calling convention
<rqou>
which for x86_64 i believe doesn't significantly change??
<cr1901>
(compared to C you mean right? Rust doesn't _have_ a public calling convention IIRC)
<rqou>
yeah, compared to the C calling convention
<rqou>
which i believe each OS now only has one
<rqou>
e.g windows x86_64 and itanium x86_64
<rqou>
no stdcall/cdecl/fastcall/thiscall/pascal/fortran/etc./etc.
<cr1901>
you forgot watcall :)
<rqou>
wat
<rqou>
really?
<rqou>
i honestly didn't know about that
<cr1901>
Watcom C's calling convention (when not targeting Windoze or Lunix)
<coino>
assembler datasheet > counting sheep
<cr1901>
azonenberg: I almost just put milk back into the cupboard instead of the fridge (b/c not thinking)... "cupboardmilk" doesn't sound nearly as catchy.
<azonenberg>
Lol
<coino>
I've put a spoon of coffee on the eggs before
<lain>
silo'd as in separate business units are not allowed to communicate directly (eg. cpu devs can't talk to network devs. or even further: firmware can't talk to hardware can't talk to software)
<pie_>
ah.
<pie_>
terrorist cells xD
<lain>
lol
<pie_>
so what i actually wanted to ask is how is multiple instructions per one clock cycle done?
<jn__>
that's horrible. how are they supposed to make good firmware, or good software that talks to the firmware?
<awygle>
my old boss was an intel guy and he was constantly paranoid about doing something that meant he couldn't work in that industry again
<pie_>
jn__, the world operates on money not progress :(
<jn__>
pie_: it's called "out of order execution"
<lain>
jn__: a friend who works at intel would probably answer that with "their job isn't to make good software/firmware, it's to do what they're told" :P
<jn__>
(and incidentally, irc is sometimes pretty out-of-order as well)
<pie_>
actually im not sure i can figure out how you even do one instruction in a single cycle
<lain>
the job sounds pretty miserable
<pie_>
$$$, top sekrit, etc, whats there to like :(
<pie_>
well i guess you get paid well
<pie_>
what % of world gdp is semiconductors? :/
<lain>
pie_: well, one instruction per cycle depends what you mean.. if it's pipelined, you can /retire/ one instruction per cycle pretty easily, as long as the stream isn't interrupted with a branch (and subsequent cache miss, such as a predictor failure)
<jn__>
pie_: doing one instruction per cycle is easy if you don't care about speed: just put all the logic in a single path, without a register in between
<pie_>
to be fair im going from having designed an extremely simple buggy cpu in a circuit simulator lol
<lain>
but also intel cpus operate on micro-ops internally afaik. e.g. a complex x86 instruction actually gets turned into a bunch of risc micro-ops (this is where microcode comes in, afaik)
<pie_>
lain, does that mean they like...have "sub-clocks"?
<lain>
pie_: ¯\_(ツ)_/¯ iunno
<qu1j0t3>
pie_: Get a hold of Hennessy and Patterson
<pie_>
i mean its just that i feel like instructions need gating in suboperations but thats just asspull assumption on my part :D
<lain>
multiple instructions in one cycle can be done a number of ways. there's VLIW (Very Large Instruction Word) where you have multiple execution units and so you can pack multiple actual opcodes per instruction word, which can execute in parallel because there's multiple copies of the execution stage
<pie_>
qu1j0t3, ive read a little of it
<jn__>
if you want to know a comparatively really simple OoO processor, i recommend reading the relevant parts of the PowerPC 750CL manual
<lain>
another form of instruction-level parallelism is doing some dependency checking and noticing that, for example, two upcoming instructions can execute in parallel because they use /different/ execution units (like a memory op and an arithmetic op), and there is no data dependency between the two ops, so the cpu can issue them both simultaneously
<pie_>
i think im hung up on the single instruction level
<lain>
when you get to where you have dependency information available, you can do all sorts of out of order shit
<lain>
pie_: well, you know about pipelining, right? :3
<pie_>
yea somewhat
<qu1j0t3>
pie_: it sounds like you're thinking about microprogramming (and yeah, pipelining once you have single instructions figured out)
<qu1j0t3>
pie_: (as lain mentioned above ofc)
<pie_>
im not thinking about anything specific just when i was designing my retarded cpu the way i made it it didnt work unless i gated some stuff with the clock xD
indy has joined ##openfpga
<qu1j0t3>
it's called a clock for a reason :)
<qu1j0t3>
pie_: Robert Baruch has a nice tutorial on a microcoded CPU on YouTube
<pie_>
im going to go put the dishes in the dishwasher in frustration
egg|work|egg has quit [*.net *.split]
<qu1j0t3>
jn__: the queue stretches around the corner and two and a half blocks
<qu1j0t3>
.b 16
egg|work|egg has joined ##openfpga
<pie_>
look ma im doing useful things :(
<jn__>
i was briefly considering to get a job at The Mill (https://millcomputing.com/#JoinUs), because they're looking for someone who's going to port a BIOS. But they don't pay a salary.
<pie_>
aw
coino has quit [Read error: Connection reset by peer]
<jn__>
they kinda do pay something ("sweat equity"), but (a) i'd need to talk to an economist/lawyer to understand how much money i'd effectively get, and (b) not sure if i'm qualified anyway
<cr1901>
You mean Mill isn't overhyped vaporware?
<jn__>
sure it's overhyped vaporware, but if they'd pay me reasonably, i'd be happy happy to contribute to the hype
<jn__>
s/happy /
<jn__>
hypothetically speaking
<pie_>
i dont suppose theres some other kind of parser thing that would have a python library and i plug the grammar into it
<pie_>
i could just leave parsing running for a couple of days and hope my caching code works
<rqou>
wtf parsing should not take on the order of days
<rqou>
get a better parser
<pie_>
i would if i knew of one
<pie_>
also might just take a few ours but i have 50 versions of the file :P
<pie_>
anyway i was just joking because theres other stuff i have to do before caching works so yeah i need a sane parser
<pie_>
this should take no more than 15-30 seconds which is how long slimit took :/
<qu1j0t3>
jn__ | hypothetically speaking // I see wut you did thar
<rqou>
alright, time to get something useful done today rather than watching vidya speedruns
<openfpga-github>
[openfpga] rqou commented on issue #78: @azonenberg and I discussed this IRL at DefCon and he mentioned that he isn't a huge fan of VPI and might consider a completely different interface for the cosimulation code. He mentioned that he has/will have something that just uses `$fread` and `$fwrite` on pipes as an example of one possible way to build a new cosimulation framework. The IRL discussion then spiraled into a discussion about whet
specing has quit [Ping timeout: 255 seconds]
<qu1j0t3>
--her tis nobler in the mind to suffer / the slings and arrows of outrageous fortune / or to take arms against a sea of troubles
<pie_>
either that or the js file actually is invalid but noone else is complaining :/
<qu1j0t3>
"Correct JS file: Parsed in 0.02sec. Incorrect JS file: Wait 1 week for answer"
<rqou>
oh yeah my parser sometimes has that problem
<rqou>
backtracking is expensive
<pie_>
hm
<pie_>
now everyone is complaining
<rqou>
although i'm not actually using a backtracking-based algorithm, but apparently bison's GLR output can still have exponential time
<qu1j0t3>
"So, I finally got a chance to run this code--"
<pie_>
nah nevermind
<pie_>
this fails on the good file too
* qu1j0t3
watched the shirriff video and now knows 2800% more about IC layout
<rqou>
or you can take a class on it? :P
<rqou>
like me
<rqou>
where i took a microfabrication class because i saw azonenberg's work on silicon RE
<qu1j0t3>
yes, i could--
<qu1j0t3>
sadly Work is usually In The Way
<qu1j0t3>
and Budgets
<cr1901>
I didn't take the microfabrication course seriously in uni (nobody did for various reasons)
<qu1j0t3>
i'm about to pay $12000 for mrsfb to take a course so well there goes my year
specing has joined ##openfpga
<cr1901>
I kinda regret this.
<qu1j0t3>
cr1901: just call it a micro-regret
* cr1901
gets the hook
* qu1j0t3
cues up Yakety Sax
<pie_>
man now im really demotivated
<awygle>
speaking of things we didn't learn in uni - anybody know of a good MOOC on parsers/parsing maybe?