<azonenberg_work> rqou: so i think i'm going to begin by finding counters without reset
<azonenberg_work> or without overflow
<azonenberg_work> iow, a chain of TFFs sharing the same reset is not a count-to-N
<azonenberg_work> it's a resettable counter
<azonenberg_work> Then, after that, infer buses
<azonenberg_work> And comparators on buses
<azonenberg_work> So a count-to-N will end up as a "resettable counter" and "compare to N" separately
awygle_m has quit [Remote host closed the connection]
awygle_m has joined ##openfpga
<azonenberg_work> ... huh funny
<azonenberg_work> i have a cascade of tff's and dff's here now
<azonenberg_work> tl;dr count[4:1] are TFFs
<azonenberg_work> count[7:5] and count[0] are DFFs
enriq has joined ##openfpga
<azonenberg_work> rqou: poke
<enriq> hello again
<enriq> I'm reading the datasheet and XAPP376
<enriq> There is something I don't understand of the OR gate
<enriq> because when describing the PLA in fig 4 there are 56 OR outputs
<enriq> for MC1 to MC56
<azonenberg_work> enriq: No, there's not
<azonenberg_work> there's 16 OR outputs for MC1 to MC16
enriq has quit [Client Quit]
awygle_m has quit [Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )]
<azonenberg_work> so not sure about count[0]
<azonenberg_work> count[4:1] are correctly inferred
<azonenberg_work> then count[7:5] are actually always zero
<azonenberg_work> but yosys isn't smart enough to see that
<azonenberg_work> and count[0] not being inferred to a TFF seems to be a bug in your tff extraction pass
enriq has joined ##openfpga
<enriq> sorry got disconnected
<enriq> azonenberg so that is an errata of XAPP376 or for some other model
azonenberg_work has quit [Ping timeout: 240 seconds]
<enriq> anyway, 16 outputs is what makes sense
<enriq> thanks
<enriq> I'might get disconnected again when I go to stir the tomato sauce
enriq has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
enriq has joined ##openfpga
enriq has quit [Client Quit]
enriq has joined ##openfpga
enriq has quit [Ping timeout: 255 seconds]
specing has quit [Read error: Connection reset by peer]
scrts has quit [Ping timeout: 246 seconds]
scrts has joined ##openfpga
azonenberg_work has joined ##openfpga
<azonenberg_work> Back
<rqou> azonenberg_work: sorry, my sleep's been a bit f*cked and i took a quick nap
<rqou> bit 0 probably doesn't get inferred as a TFF because it always toggles
digshadow has quit [Quit: Leaving.]
<rqou> which doesn't currently get inferred as "TFF with constant 1"
<azonenberg_work> Yeah
<azonenberg_work> rqou: i'm patching that already
<azonenberg_work> gimme a sec
<azonenberg_work> I'm extracting TFF_P_ALWAYS_ cells, then using techmap to replace them with TFF_P with T=1
scrts has quit [Ping timeout: 240 seconds]
<rqou> btw azonenberg_work have you seen this? https://www.google.com/patents/US8024688
<azonenberg_work> Looking
<azonenberg_work> rqou: ok so two separate issues
<azonenberg_work> first is, inverter isn't inferred because it isnt a xor
<azonenberg_work> secon dis, first stage has inverter after rather than before
<azonenberg_work> the dff
<azonenberg_work> second is*
<azonenberg_work> Working on that
<rqou> anyways, about my distraction, do you think xilinx actually deployed that?
scrts has joined ##openfpga
<azonenberg_work> Never heard of it
<azonenberg_work> Doubtful
<rqou> why do they have a patent on it? just lawyers?
<azonenberg_work> Probably somebody decided to patent it in case they decided to use it
<azonenberg_work> But decided it wasnt a priority
<azonenberg_work> Also hmm, my mapping isnt working :(
<rqou> aka "lawyers being lawyers" :P
<azonenberg_work> Lawyers gonna lawy
<rqou> also, why is this even patentable? seems pretty obvious to me
<azonenberg_work> It's patentable because nobody ever took xilinx to court to claim it shouldn't be
<azonenberg_work> :p
<rqou> ah, just like how linked lists are patentable :P
<cr1901> They patent cures for cancer...
<azonenberg_work> Of course
<azonenberg_work> A person with cancer is going to spend any money they can get on curing it
<azonenberg_work> It's a cash cow
<azonenberg_work> you can charge as much as you want and they'll pay
<azonenberg_work> Or, their insurance company will
<azonenberg_work> Also grrr my TFF inference is failing
<rqou> TFF inference isn't super reliable because of how many duals are possible
<rqou> i wonder if giving the FFs to abc will help at all?
<rqou> abc can supposedly do retiming, which we might be able to abuse
<azonenberg_work> ... oh wait
<azonenberg_work> i see
<azonenberg_work> Gimme a bit
<azonenberg_work> What does -g on abc do again?
<rqou> limit to these gates
<rqou> it always adds NOT to the list
<rqou> and no, it can't be only XOR :P
<azonenberg_work> It always adds nots
<azonenberg_work> That was my quesiton
<azonenberg_work> ok boat is docking
<azonenberg_work> Gonna poke at this more when i get home in half an hour
<rqou> abc might be hardcoded to assume the availability of NOT
azonenberg_work has quit [Ping timeout: 260 seconds]
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
enriq has joined ##openfpga
enriq has quit [Remote host closed the connection]
<openfpga-github> [yosys] azonenberg pushed 3 new commits to master: https://git.io/v796x
<openfpga-github> yosys/master da98966 Andrew Zonenberg: Continued work on debugging recover_tff
<openfpga-github> yosys/master fc9a90d Andrew Zonenberg: tff_untechmap: Added indentation for clarity
<openfpga-github> yosys/master a80121b Andrew Zonenberg: Added TFF_x_ALWAYS cells
digshadow has joined ##openfpga
azonenberg_work has joined ##openfpga
awygle has quit [Ping timeout: 260 seconds]
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
enriq has joined ##openfpga
<openfpga-github> [yosys] azonenberg pushed 1 new commit to master: https://git.io/v79Pr
<openfpga-github> yosys/master 6531666 Andrew Zonenberg: Removed always-toggle TFF support. Going to move this to counter extraction.
ZipCPU_ has joined ##openfpga
ZipCPU has quit [Ping timeout: 260 seconds]
dohzer has quit [Quit: Leaving]
_whitelogger has joined ##openfpga
<enriq> oh well ok I guess I need to specify in verylog
<enriq> very very log
awygle has joined ##openfpga
<awygle> hello world
<azonenberg> ohai
<awygle> so azonenberg, i'm starting on some literature review. want to make sure understand a) where you're at b) where you're going so i don't flood you with irrelevancies.
<awygle> is it correct to say that post-bitstream-RE, you basically have a gate-level netlist?
<azonenberg> Ok
<azonenberg> So the flow is as follows
<azonenberg> first, technology specific front end
<azonenberg> so FPGA/CPLD bitstream, or eventually SEM photos of an ASIC die, turns into a netlist in the native cell library for the target device
<azonenberg> Second step is to un-techmap that with behavioral models of each of those cells (leaving complex / mixed signal hard IP unmapped, so it's a black-box primitive)
<azonenberg> Then optimize with ABC to get an AIG
<azonenberg> Techmap to yosys's internal generic cell library
<azonenberg> at which point we have a technology-independent gate level netlist
<azonenberg> This is the IR that all further analysis passes run on
<azonenberg> gradually extracting more and more complex structure on
<azonenberg> and thus we can do this analysis independent of the original cell library or technology
<azonenberg> I'm looking for any published work on such approaches, especially if for RE rather than synthesis
<azonenberg> although i suspect there will be a lot of overlap with coarse grained synthesis work
<awygle> right
<awygle> okay
<azonenberg> But even if a lot of our algorithms already existed for synthesis, doing it for RE is still novel
<awygle> i love really out-of-place citations in academic papers. i can just see the professor going "your references are a little light..."
<awygle> azonenberg: anywhere in particular you want my results stored?
<azonenberg> make a new wiki page?
<awygle> k
<enriq> which is a good tutorial to verilog
<rqou> lol none :P
<enriq> damm
<enriq> there are too many things
<rqou> nobody is good at verilog, everybody has slightly different coding styles, etc. etc.
<enriq> reg, wire, output, input
<rqou> reg vs wire is totally frivolous
<enriq> reg=wire?
<rqou> i have no idea why there was a distinction in the first place
<rqou> no, they're not
<rqou> azonenberg: what's the difference? :P
<rqou> i'm not actually good at verilog
<enriq> I try to formalise my adc
<azonenberg> you assign a wire, you always a reg
<azonenberg> wire = combinatorial
<azonenberg> reg = either combinatorial or sequential depending on what block it's in
<enriq> I would like a tutorial showing real logic circuits expressed in verylog
<enriq> but complex things not just a stupid FF
<enriq> but I think the idea of verilog is wicked
<enriq> I keep writing verylog instead of verilog
<enriq> my adc will have a serial output which adds fun
<enriq> you would never get the same as the real 4017
<enriq> which is 4 FF, like 10 and gates for the combinations, and a couple more to make the FFs output 00000, 10000, 11000, 11100, 11110, 11111, 01111, 00111, etc
<enriq> how is that code called btw
<enriq> how would that 4017 code be synthethised ?
<rqou> you can always throw it into yosys and see :P
enriq has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
enriq has joined ##openfpga
<enriq> I'll try, I compiled yosys today
<rqou> btw, if you trust binaries compiled by some dude on the internet, https://rqou.com/jenkins/job/open-fpga-tools/
<enriq> ah cool
<enriq> but hm what do I do with yosys, write_ilang?
<rqou> "show" is pretty neat
<enriq> oh I need gv
<enriq> what is a good dev workflow including verilog?
<rqou> azonenberg?
<enriq> I mean you write the .v, then simulate with icarus?
<rqou> i don't do nearly as much "real" hdl dev as you might think :P
<enriq> then check the output with yosys
<enriq> or the old times, burn chips and test with leds :)
<enriq> then erase with UV lamp
<rqou> fortunately we don't need to do that anymore
<awygle> enriq: basically write the .v, simulate with icarus if you like, synthesize with yosys, place, route, generate bitstream, program to chip
<rqou> you forgot various steps that "real" devs do like "mess with custom perl scripts"
<rqou> "run various code generators"
<rqou> or "do formal verification"
<awygle> in your case since you're doing place, route, and generate by hand, simulate, synthesize, then look at the synthesized output
<enriq> from yosys output I can write the jed more or less?
<awygle> rqou: s/perl/tcl/
<rqou> BRCM had lots of perl, not nearly as much tcl
<enriq> sounds good
<enriq> I'm brew installing gv to check the yosys show
<enriq> takes time on wife's machine, mine died
<awygle> enriq: the yosys output isn't "placed". so you have to figure out for yourself where you want the cells to go on the chip
<enriq> yes, I have a rough idea
<enriq> (for my limited case)
<awygle> three and a half papers, i have six more open and the citations tree is still getting bigger and more interesting but i need some sleep. more tomorrow
<rqou> yeah i'm pretty tired and unproductive today because i stayed up too late last night coding
<awygle> instead of doing one big all-night push i have been getting ~5h sleep the last ~7 days, it is catching up with me
scrts has quit [Ping timeout: 240 seconds]
<awygle> i did approximately one useful thing at work today
<azonenberg> yeah i've been crazy overloaded at work lately
<awygle> reddit, of course, has the perfect gif: http://galshir.com/life-balance/galshir-life-balance-gif.gif
<azonenberg> but trying to make some research progress before my two weeks of hiking and camping (planned a year or so in advance, family is flying in from the other side of the country)
<azonenberg> then two weeks on site with a client i'll hopefully get some dev during
<azonenberg> then one more week, then the con
<rqou> i will be basically gone next week because classes start
<azonenberg> This weekend i want to finish counter extraction and finish my slide deck showing where we are now
<azonenberg> During the onsite i'll have free time in the evenings, no wife demanding my attention or anything :p
<rqou> azonenberg: anything you want me to urgently work on?
<azonenberg> So i'll be coding all night
<rqou> have you tried not having a wife? :P
<azonenberg> Yes, i did
<rqou> unfortunately, not having a wife means that you actually need to do household chores :P :P :P
<azonenberg> Yes, lol - it also means nobody home during the day to sign for packages, or force me to do all of the things i don't really want to do but need to :p
scrts has joined ##openfpga
coino has quit [Ping timeout: 240 seconds]
<rqou> you can have the arrangement i have here:
<rqou> nobody does household chores
<rqou> whenever $HOUSEMATE's sister comes and visits, she complains a whole bunch
<rqou> and then does a bunch of the chores :P :P :P
<enriq> oooooohhhhhh
<enriq> I don't understand a thing from show output but is nice
<rqou> so one possible script you can try is:
<rqou> read_verilog <foo.v>
<rqou> proc
<rqou> synth
<rqou> techmap
<rqou> abc
<rqou> clean
<rqou> and then show
<enriq> ok let me see
<enriq> it generated a huge thing
<enriq> I guess that 4017.v is really bad
<enriq> but if I think the design in terms of logic design, like if I were using old 7400 or 4000 chips
<enriq> for example, for the 16 bit counter I just need to configure the FF as T, wire the T to 1, then wire Q_n to Clk_n+1 and little more
<rqou> welcome to exactly what azonenberg and I are working on right now :P
<enriq> synthethise a counter?
<rqou> take that giant mess and discover that it is indeed a counter
<enriq> yeah I see
<enriq> I don't like verilog :)
<enriq> people really design like that?
<rqou> some people use vhdl instead
<rqou> it's not clearly better
<enriq> for the serial transmision of the counter output, what I'm thinking is creating a mux from the counter output and on each clock, put 1 of the bits in the data output
<awygle> enriq: a lot of people are really bad at verilog. i'm not sure why. something to do with either "i don't understand hardware" or "i don't understand programming languages" makes a "hardware description language" really hard to grok for some people
<enriq> do you have some good examples?
<rqou> i mean, i like to think i understand both hardware and PL, but i still think HDLs suck
<awygle> on the other hand, a counter is just "reg [7:0] count; always @(posedge clk) count <= count + 1;", which is unquestionably smaller than a schematic with 8 flip flops.
<enriq> I can see that the idea of "modules" is to encapsulate a hardware component
<awygle> "a picture's worth a thousand words" goes both ways
<enriq> but then the description inside... I don't know
<rqou> lol awygle
<rqou> that example is the exact same example my father used to get the company to switch to HDL design entry a few decades ago
<awygle> rqou: yeah i think they suck too but... i dunno, not fundamentally?
<rqou> previously it was full of old farts using schematic capture :P
<awygle> like, all the stuff around the language sucks so badly i can't even tell if the language sucks yet
<enriq> being more of the software world, I can see that an abstraction is useful
<rqou> imho verilog isn't particularly bad, but it has a ton of footguns and isn't very "powerful" unlike modern programming languages
<awygle> because nobody actually implements it, and none of the tools work, and if a tool does work it does 1/100th of what you need and can't be interfaced with anything else
<enriq> but then you need the wiring to be the best possible, else you would use c on a microcontroller :)
<rqou> vhdl thinks it's very powerful but everything is slightly gimped
<awygle> whine whine complain
<awygle> vhdl seems interesting. apparently the "real" FPGA guys at work use it, i've been trying to read it lately
<awygle> more different from verilog than i'd have expected
<enriq> so people use verilog or vhdl as "spec" and then write the jed by hand?
<rqou> btw the vhdl spec is _huge_
<awygle> enriq: very no
<rqou> almost nobody uses most of the features, but if you "cheat" and don't implement them, you won't be able to graft them in later
<rqou> vhdl has a very very powerful type system
<rqou> but then it's gimped because it doesn't have type inference at all
<rqou> wait awygle you're in the US and using VHDL? impossibru :P
<awygle> verilog (or vhdl) is a description of a circuit. you can write it at a variety of levels - transistors, gates, or "behavioral"
<enriq> awygle I like your counter. but how would you specify a decade counter?
<enriq> where outputs are 100000, 01000, 001000 and so on
<awygle> then the HDL description is "synthesized" into an equivalent circuit implemented with the circuit elements that are actually available on the chip (typically in a representation called a netlist)
<awygle> automatically
<awygle> then the placer and router place the circuits on the chip in terms of x/y coordinates and figure out what the muxes and buffers need to be set to to make the thing actually work, and the .jed is generated based on what they come up with (again, automatically)
<awygle> uhh one sec, i'll try and whip that up i suppose
<enriq> I think that you need somehow to use only elements with known "optimal" synthesis for a given chip
<rqou> HDL synthesis isn't optimal
<rqou> it's just "good enough"
<awygle> that is only (possibly) true if you are designing at the absolute margin. i.e., if your design _exactly_ fits on the chip with _nothing_ to spare
<awygle> otherwise you just need something good enough as rqou says
<rqou> occasionally insane people like my father or sb0 will bypass hdl and do something crazy to get better performance or to do something the tools weren't designed to do
<enriq> and if you can be a bit lossy about timing
<awygle> you seem to be thinking about it like you're going to put each logic element on the board. but you're not - the coolrunner has the resources it has, and if you don't need them all, then you have slack to play with
<enriq> anyway I'm the fading generation :)
<enriq> I mean
<awygle> also as an engineer you're expensive. i can pay you to hyper-optimize the design, or i can pay 0.02c more per unit for the 64a instead of the 32a.
<rqou> awygle you're obviously not making a toy or something :P
<enriq> and replace my by a monkey
<enriq> they have tried
<enriq> it does not work
<awygle> similarly time to market is important - if geohot's xbox modchip beats mine to market he gets all the glory and we can't have that
<enriq> my salary negotiation for the last 10 years was "ok, replace me by 4 juniors"
<awygle> i'm not saying i don't need skilled people, i just want to have them working on important things, not hand-editing JEDs
scrts has quit [Ping timeout: 246 seconds]
<awygle> you're smart, i want you doing my differentiator, whatever that is
<awygle> anyway. that's my perspective on it. i'ma go write a decade counter :P
<rqou> btw once we actually finish it, the openfpga coolrunner flow can explicitly place _every_ primitive including p-terms
<enriq> haha please
<rqou> so there should never be a use case for hand-editing jeds once it actually works
<rqou> er wait
<rqou> no, you can't override zia muxes right now
<rqou> i'll think about how i might add that
<enriq> what you mean
<rqou> signals can exit the zia and enter the AND array in multiple locations
<rqou> right now you cannot select which one
scrts has joined ##openfpga
<rqou> the PAR tool will try to pick ones that fit
<enriq> you mean "on runtime"?
<enriq> ah
<rqou> normally this doesn't matter because these paths should all have the same timing
<enriq> yes
<rqou> but who knows, you might be doing something weird :P
<enriq> I would sleep better if the 16 FF are in the order of their MC number :)
<enriq> like bit 0 is MC1, bit 1 is MC2
<enriq> I would wake up in the middle of the night screaming if they're not ordered
<awygle> https://gist.github.com/awygle/e08a06ef13ace769447283f99d084a1d this should do it, unless i'm a derp
<awygle> i am a derp, hang on
<enriq> I like you use leds
<awygle> okay, sold
<awygle> hit refresh
<enriq> for i=0 or 1?
<awygle> 1 because otherwise you end up with leds[-1]
<enriq> ah no
<enriq> ok
<awygle> which... might work? but probably doesn't
<enriq> you need to turn on the first one
<awygle> true
<enriq> on reset i guess
<awygle> man i'm tired.
<enriq> yeah
<enriq> me too
<enriq> 3:20AM
<enriq> but you're great, thank you
<awygle> okay hit reset again, i did that and i made the width generic
<awygle> so you can parameterize how many bits you want
<enriq> ok I downloaded it
<enriq> I'll test tomorrow
<enriq> thank you :)
<enriq> on return the jed file will be free to download :)
awygle_ has joined ##openfpga
<enriq> wait the jed file is a text file with binary in ascii
<awygle_> enriq: last fix, i fixed the reset to be properly parameterized
<azonenberg> enriq: yes
<azonenberg> It's similar to a motorola hex file
<enriq> piece of cake :)
<azonenberg> (.mcx / .hex)
<enriq> yes
<azonenberg> but ascii binary instead of ascii hex
<rqou> i believe the spec has a hex mode too?
<azonenberg> enriq: there's a few checksums, but they're optional and you can bypass them
<azonenberg> rqou: not that i know of
<awygle_> and now i'm going to bed. goodnight everyone. also if anybody wants to glance at that gist and tell me about anything stupid i'm doing, i'd appreciate the feedback
<rqou> i've never seen it and i don't think the xilinx tools accept it
<azonenberg> its been a little while since i read the spec
<enriq> good night, thaks
<azonenberg> enriq: if you must, JESD3-C
<enriq> it's the same as jedec right?
<azonenberg> it's a public spec
<azonenberg> JEDEC is an organization, the .jed file format is a ROM image format they standardized
<azonenberg> Which is what coolrunner tools use
<azonenberg> In case that wasn't fun enough, the JED file is not actually what you feed to the chip
<azonenberg> JESD3-C says that you are supposed to be able to just write those addresses to the chip
<azonenberg> But xilinx made the JED file virtually addressed instead of physically :p
awygle has quit [Ping timeout: 260 seconds]
<rqou> azonenberg: sorry, only the "E" command can be hex
<azonenberg> Which makes it massively easier to write, but means your jtag tool has to convert to physical addressing when flashing the chip
<rqou> which is for "feature fuses that do not affect the logic function of the device"
<rqou> the "L" command cannot be hex
<azonenberg> rqou: Thought so
<enriq> I see
<enriq> so the tool just parses the .jed and kind of linkedits it for a given chip, and then generates the jtag commands
<azonenberg> It's not linking exactly, it's just shuffling the addresses around
<azonenberg> sec, let me show you a figure
<azonenberg> As of that talk the RE was not done, the text file has some additional information beyond what i knew back in 2015
<azonenberg> But it has a good arhcitecutral overview etc
<azonenberg> Look at slide #16
<azonenberg> enriq: then slide 17 is zoomed in and more labeled
<azonenberg> In slide 16 you can see roughly where the JTAG shift register is (horizontally across the chip somewhere between TDI and TDO, we don't know *exactly* where it is)
<azonenberg> basically each of the 48 JTAG scan operations during the flashing operation loads one row of that eeprom
<azonenberg> Which, during boot, is copied to one "scanline" across the logic array
<azonenberg> So you get 9 bits of the left hand macrocell config, 112 bits of PLA config (AND or OR depending on which row you're in), 16 bits of ZIA (interleaved from left to right), then it repeats mirror image to the other side of the die
<azonenberg> See slide 19
<enriq> oh you need to reorder the things from a logical view to a physical array
<azonenberg> Exactly
<azonenberg> the jed is logically addressed
<azonenberg> Which violates the JEDEC standard, since it's supposed to be something you can flash directly (like a .hex)
<azonenberg> But it does make creating a toolchain, or writing one by hand, a lot easier
<rqou> oh btw the 9500/9500xl jed files are _also_ logically addressed
<enriq> and you're using the xilinx tool to flash?
<rqou> but the remapping is simpler
<rqou> i'm using a giant hack right now
<azonenberg> enriq: I'm using my own tool, mostly, but you can use any of several options
<azonenberg> i think xc3sprog can do it
<rqou> i'm using impact to load our jeds and convert them to svf
<rqou> and then i use openocd to "play" the svf
<rqou> this is in the queue to be rewritten but is much lower priority
<rqou> oh btw azonenberg: i tried to find programmer qualification documents for 9500/9500xl and they have a high-voltage parallel programming mode?!
<azonenberg> o_O
<rqou> whereas the jtag is completely undocumented
<azonenberg> Lolol
<azonenberg> I mean it shouldnt be hard to re the jed-to-svf mapping
<rqou> we already have that
<enriq> your own tool is part of openfpga?
<rqou> crbit should be in svf ordering (+/- some mirroring)
<rqou> and some padding
<azonenberg> rqou: i meant for 9500
<rqou> ah
<rqou> azonenberg's jtag tool is a giant mess right now :P
<azonenberg> enriq: No, it's in libjtaghal, which is also open source and on my github but is part of a larger project and (currently) hard to compile by itself
<enriq> ok. but it's the only option for mac I guess
<rqou> as you might notice, everything is a bit WIP :P
<enriq> other than a virtualbox with linux of course
<enriq> everything rocks
<enriq> ok morning birds started to sing
<azonenberg> Yeah this is ongoing research, none of the toolchains are mature enough that we can start polishing them for general purpose use
<enriq> I should sleep
<enriq> sure
<rqou> although the greenpak4 stuff is much more working
<rqou> and even works on mac
<rqou> including for programming
<azonenberg> yeah
<enriq> ok I'll try to create the verilog of my adc with serial output, then write the jed
<azonenberg> That is not feature complete, but is fairly stable
<azonenberg> and has no known bugs producing incorrect output
<azonenberg> There are known unsupported features (that fail with an error), and known situations where a design that should fit doesn't
<azonenberg> but if it says your design fits, and PARs correctly, then (to my knowledge) the bitstream should always match your logic
<enriq> I will try greenpak when time comes. after the adc. and in any case good night gentlemen
enriq has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
<azonenberg> rqou: Ok, i'm now finding chains of TFFs
<rqou> nice
<azonenberg> Not doing anything with the chains yet
<azonenberg> but its a start
<rqou> azonenberg: anything you want me to go work on?
<azonenberg> Yeah, actually
<azonenberg> Make a "infer bus" pass
<azonenberg> that looks at parallel outputs from various cells like adders and shregs
<azonenberg> and declares them to be a named bus
<azonenberg> rather than N discrete bits
<rqou> hmm ok
<azonenberg> And, after that (or as part of the same thing)
<azonenberg> turn scalar top-level ports connected to buses into vector ports
<azonenberg> We'll worry about inputs later, at least for commutative operations like addition
<rqou> probably tomorrow though, not tonight
<azonenberg> yeah no rush
<azonenberg> So my current code anchors on the first TFF
wolfspraul has quit [Quit: leaving]
<azonenberg> goes towards the MSB until it stops seeing TFFs in series with ANDNOTs
wolfspraul has joined ##openfpga
<azonenberg> the LSB is driven by a NOR
<azonenberg> problem is, the NOR is driven by two DFFs
<azonenberg> have to figure out which is the one i want
<azonenberg> ... tomorrow
<rqou> yeah, i've found a lot of the primitive extraction has trouble at the MSB/LSB
<cr1901> well I guess I'm awake now... now, what to do until breakfast time...
<rqou> subtractors have problems with MSBs
<azonenberg> The other issue i am having is
<cr1901> Maybe I'll start on the shreg fix
<azonenberg> the counter right now is 8 bits in theory
<azonenberg> in practice its 5 bits with 3 unused high bits
<azonenberg> but the optimizer isnt smart enough to realize that the wires are initialized to zero, and once zero can never become one the way the feedback works
<azonenberg> So they're actually constant zero
<azonenberg> aaaanyway bedtime
<cr1901> hopefully your bed is nice and comfy
<cr1901> unlike mine, which the cat puked on
<rqou> yeah, the optimizers occasionally amaze me with how smart they are, and then they occasionally disappoint me with how dumb they are
specing has joined ##openfpga
scrts has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
m_t has joined ##openfpga
eduardo_ has quit [Read error: Connection reset by peer]
eduardo has joined ##openfpga
qu1j0t3 has quit [Ping timeout: 248 seconds]
qu1j0t3 has joined ##openfpga
promach__ has joined ##openfpga
promach__ has quit [Remote host closed the connection]
promach__ has joined ##openfpga
ZipCPU_ is now known as ZipCPU
scrts has quit [Ping timeout: 246 seconds]
scrts has joined ##openfpga
promach__ has quit [Quit: Leaving]
promach__ has joined ##openfpga
GenTooMan has joined ##openfpga
promach__ has quit [Quit: Leaving]
promach__ has joined ##openfpga
m_t has quit [Quit: Leaving]
lexano_ has quit [Ping timeout: 240 seconds]
lexano_ has joined ##openfpga
HTTP_____GK1wmSU has joined ##openfpga
HTTP_____GK1wmSU has left ##openfpga [##openfpga]
promach__ has quit [Ping timeout: 246 seconds]
promach__ has joined ##openfpga
teepee has quit [Ping timeout: 245 seconds]
teepee has joined ##openfpga
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
awygle_ is now known as awygle
enriq has joined ##openfpga
enriq has quit [Quit: Mutter: www.mutterirc.com]
enriq has joined ##openfpga
enriq has quit [Client Quit]
promach__ has quit [Quit: Leaving]
pointfree1 has quit [Ping timeout: 240 seconds]
Guest78256 has quit [Ping timeout: 258 seconds]
teepee has quit [Ping timeout: 240 seconds]
teepee has joined ##openfpga
specing has quit [Ping timeout: 240 seconds]
specing has joined ##openfpga
pointfree1 has joined ##openfpga
coino has joined ##openfpga
indy has quit [Ping timeout: 240 seconds]
* coino o/
indy has joined ##openfpga
Guest400 has joined ##openfpga
enriq has joined ##openfpga
enriq has quit [Remote host closed the connection]
enriq has joined ##openfpga
digshadow has quit [Ping timeout: 240 seconds]
enriq has quit [Client Quit]
eduardo_ has joined ##openfpga
eduardo has quit [Ping timeout: 246 seconds]
scrts has quit [Ping timeout: 240 seconds]
digshadow has joined ##openfpga
scrts has joined ##openfpga
digshadow has quit [Ping timeout: 246 seconds]
m_t has joined ##openfpga
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
Marex has quit [Ping timeout: 276 seconds]
D33P-B00K has joined ##openfpga
Marex has joined ##openfpga
D33P-B00K has left ##openfpga [##openfpga]
scrts has quit [Ping timeout: 240 seconds]
enriq has joined ##openfpga
scrts has joined ##openfpga
scrts has quit [Ping timeout: 240 seconds]
dingbat has joined ##openfpga
scrts has joined ##openfpga
enriq has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
DingoSaar has joined ##openfpga
DingoSaar has quit [Max SendQ exceeded]
DingoSaar has joined ##openfpga
scrts has quit [Ping timeout: 246 seconds]
scrts has joined ##openfpga
enriq has joined ##openfpga
enriq has quit [Client Quit]
enriq has joined ##openfpga
<pie__> why does ecc ram need extra mobo and cpu support?
<pie__> also fuq i didnt think this would be so expensive :'C https://www.amazon.com/Crucial-Single-PC3L-12800-204-Pin-SODIMM/dp/B0123BRIDK
<jn__> pie__: extra traces for the extra bits?
<pie__> id expect the memory itself to handle the error correction?
<jn__> and the memory controller needs to handle the additional complexity, too, i guess
scrts has quit [Ping timeout: 248 seconds]
<pie__> though i guess that could be mor eflexible with direct access, but then why not just do ecc in software with normal ram?
<jn__> (note that i really don't know a lot about ram)
<pie__> i doubt ecc has the CPU constantly scannning through the entire ram for errors
<pie__> (i dont either)
<jn__> doing ECC in software sounds painful
<qu1j0t3> pie__: Yes, RAM scrubbing *is* a thing. Also the operating system keeps tabs on ECC errors.
<qu1j0t3> pie__: (RAM scrubbing is how you make memory ECC work, like disk scrubbing in ZFS)
<pie__> idk how disk scrubbing works in zfs :P
<jn__> (also [half trolling]: 16GB? my most recent acquisition has 256MiB DIMMs, and they are massive: http://i.ebayimg.com/images/g/9NgAAOSwA3dYf8Be/s-l300.jpg)
<qu1j0t3> eh well, if you have self healing it's much less effective if the errors are latent. scrubbing discovers them.
<pie__> qu1j0t3, i would have expected firing an interrupt when an ecc subcircuit detects an error or something
<qu1j0t3> pie__: Otherwise you only discover them by accident, and likely at a much worse time
<qu1j0t3> pie__: You still want scrubbing
<pie__> i would have expected constant self checking with the normal refresh thing and a notification to the cpu when an error is detected and whether it was corrected or uncorrectable
enriq has quit [Quit: Mutter: www.mutterirc.com]
<qu1j0t3> scrubbing is not done autonomously by RAM, no
<pie__> (ffs wine is still compiling ugh xD)
<pie__> but why not???
scrts has joined ##openfpga
<qu1j0t3> it would be much more expensive. is probably the main reason
<qu1j0t3> it doesn't need to
<pie__> better to have that complexity in te cpu memcontrolre and not need to deal with it in ram?
<qu1j0t3> pie__: Most servers are massively underutilised. there is cpu to burn.
<pie__> but then why have ecc in hardware and not just do it in software?
<qu1j0t3> pie__: to have memory do that would be significantly more complex in hardware
<qu1j0t3> pie__: (I'd estimate. i could be wrong)
<qu1j0t3> pie__: (but this is kind of a non problem)
<pie__> well it seems fair enough
digshadow has joined ##openfpga
<qu1j0t3> pie__: what you say about refresh makes sense. Maybe that would be easy. I'll shut up now because I'm not an expert on this.
GenTooMan has quit [Read error: No route to host]
<pie__> qu1j0t3, you know more than i do so if anything i should be quiet ;P
<pie__> even if neither of us knows anything xD
<pie__> armchair architects
<pie__> xD
m_t has quit [Quit: Leaving]
DingoSaar has quit [Remote host closed the connection]
enriq has joined ##openfpga
DingoSaar has joined ##openfpga
enriq has quit [Ping timeout: 246 seconds]
cr1901 has quit [Ping timeout: 246 seconds]
Guest400 has quit [Ping timeout: 255 seconds]
pointfree1 has quit [Ping timeout: 240 seconds]
fpgacraft1 has quit [Quit: ZNC 1.7.x-git-709-1bb0199 - http://znc.in]
fpgacraft2 has quit [Quit: ZNC 1.7.x-git-709-1bb0199 - http://znc.in]
fpgacraft1 has joined ##openfpga
fpgacraft2 has joined ##openfpga
X-Scale has quit [Ping timeout: 246 seconds]
laintree has quit [Ping timeout: 255 seconds]
laintree has joined ##openfpga
enriq has joined ##openfpga
pointfree1 has joined ##openfpga
enriq has quit [Ping timeout: 258 seconds]
enriq has joined ##openfpga