awygle_m has quit [Ping timeout: 248 seconds]
<pointfree> I just noticed something peculiar about the 512M unused region between FLASH and SRAM on my PSoC 5LP. When I flash an image to the 256KiB flash the same image is mapped every 256KiB of the 512MB unused region. I thought this region was supposed to be unmapped?
<whitequark> missing address bits?
<pointfree> It could be space for more flash or sram.
<cr1901_modern> Probably got "lazy" with the address decoder (like everyone on the planet does)
<pointfree> cr1901_modern: yeah that might explain it. I could use that last 256KiB of that unused region for relative addressing between SRAM and flash.
<pointfree> whitequark: Perhaps those missing address bits can be enabled or disabled in the factory(?)
enriq has joined ##openfpga
<rqou> oh goddammit amdgpu/radv crashed my gpu again
<rqou> i swear nobody tests this
digshadow has quit [Ping timeout: 240 seconds]
digshadow has joined ##openfpga
ZipCPU|Laptop has quit [Ping timeout: 260 seconds]
digshadow has quit [Ping timeout: 264 seconds]
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
digshadow has joined ##openfpga
eric_j has quit [Read error: Connection reset by peer]
eric_j has joined ##openfpga
GenTooMan has quit [Quit: Leaving]
ZipCPU|Laptop has joined ##openfpga
X-Scale has quit [Quit: HydraIRC -> http://www.hydrairc.com <- Chicks dig it]
<rqou> wait wait wait
<rqou> azonenberg_work: i have a potential "target" for our RE work
<rqou> unfortunately still requires writing more code
<rqou> azonenberg_work: we really really need an ice40->yosys tool
<rqou> apparently the HTC vive/steamVR setup uses a number of ice40s
<rqou> so there's a fun test bitstream :P
<rqou> plus, it would be neat to RE anyways
<rqou> i wonder if the fpga bitstream is in one of the software updates?
<rqou> otherwise you can try to convince your employer to buy you an htc vive? :P :P
<rqou> (or possibly just the controller, which also has an ice40)
lexano has quit [Ping timeout: 252 seconds]
lexano has joined ##openfpga
Hootch has joined ##openfpga
digshadow has quit [Ping timeout: 260 seconds]
digshadow has joined ##openfpga
pie__ has quit [Read error: Connection reset by peer]
pie_ has joined ##openfpga
awygle_m has joined ##openfpga
pie__ has joined ##openfpga
pie_ has quit [Ping timeout: 264 seconds]
<mithro> Anyone know of a good C library for talking etherbone?
<rqou> <troll>use antikernel noc instead</troll>
awygle_m has quit [Remote host closed the connection]
<rqou> oh wait, is this just tunneling wishbone over "real" ethernet?
<rqou> not abusing ethernet for a NoC?
pie__ has quit [Read error: Connection reset by peer]
pie__ has joined ##openfpga
<Morn_> Do I see that right that there are no open-source HDL simulators that can compete with commercial ones like ModelSim? (SystemVerilog, Mixed language support etc.)
pie__ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
m_t has joined ##openfpga
<ZipCPU> No, you don't.
ZipCPU|Laptop has quit [Quit: Transitioning to a lower energy state]
enriq has joined ##openfpga
<azonenberg_work> rqou: lol ok so write an ice40 front end
<Morn_> ZipCPU: So which software am I missing?
<Morn_> I am thinking about writing a HDL simulator myself, so I want to do some research to see if it will be really helpful for people
azonenberg_work has quit [Ping timeout: 248 seconds]
<ZipCPU> Morn_: I use Verilog as an open source HDL simulator. In many ways, it runs faster than the commercial simulators, although it doesn't have mixed language support.
<Morn_> which simulator?
<ZipCPU> Sorry ... I said Verilog, I meant Verilator.
<Morn_> ah
<Morn_> I also heard very good things about Verilator
<Morn_> But there is no support for SystemVerilog
<ZipCPU> Verilator does support SystemVerilog.
<Morn_> Hmm on the website says it supports only synthesizable Verilog and "some SystemVerilog features"
<ZipCPU> You can read about how/why I love it here: http://zipcpu.com/blog/2017/06/21/looking-at-verilator.html
<ZipCPU> One of the things Verilator allows you to do, which the other simulators tend not to, is to build peripheral co-simulators.
<ZipCPU> For example, I just built an HDMI source simulator, and expect to build an HDMI display simulator in due time.
<ZipCPU> The other thing you can do with Verilator is integrated simulation: where you put all your parts and pieces together, with simulated peripherals, and simulate the whole.
<ZipCPU> Doing so, though, requires a Verilog only design.
<ZipCPU> (SystemVerilog is accepted ...)
<Morn_> what do you mean with peripheral co-simulator?
<Morn_> if you want to write any complex test bench code you have to do it in C++ right?
<ZipCPU> Let's see ... peripheral co-simulator ... the article above references how I do that from C++, for simulating UART's, QSPI flash devices, VGA, SDRAM, SD-Card, OLEDrgb, and more.
<ZipCPU> As for test bench code, I've now got it driving Verilog designs having multiple clocks within them. I haven't taught it how to handle changing clock rates, but ... that's just a matter of time.
<Morn_> But that is all possible with pure SystemVerilog or even Verilog too isn't it?
<ZipCPU> I do it all with pure Verilog (plus C++ simulation code).
<ZipCPU> I've also got an I2C simulator, SPI-based A/D simulator ...
<Morn_> Hm that indeed looks very cool
<ZipCPU> Almost forgot, there's an ethernet simulator as well ... but it doesn't connect the ethernet port to a real-ethernet port as I might like.
<Morn_> Do you know about SystemVerilog's Direct Programming Interface (DPI)?
<ZipCPU> I could ... I just haven't gotten that far.
<ZipCPU> Heard about DPI.
<ZipCPU> Verilator does support DPI--I've just never used it.
<Morn_> Hmm interesting
<ZipCPU> Other open source simulators I know of / heard of include iverilog and ghdl+cocotb.
<Morn_> yeah i used ghdl before
<Morn_> I just want to find an excuse why I should write my own one =)
<ZipCPU> Ok, let me provide you with that excuse ...
<ZipCPU> It's very difficult to do peripheral-cosimulation with your design. While I can do so easily with Verilator, I've never been all that pleased with the capabilities I've read to do that with VHDL.
<Morn_> :D :D
<ZipCPU> It would be nice to hvae a simulation capability that allows you to simulate your code, whether Verilog, SystemVerilog, VHDL, etc., while also allowing you to simulate your peripherals at the same time.
<ZipCPU> I have a personal preference for simulating peripherals within C++, but the need for a solution doesn't require C++.
<Morn_> hmm
<Morn_> doing the testbench stuff in c++ actually sounds very nice
<ZipCPU> If Verilator were given a mixed language capability, that might be a good start.
<ZipCPU> There's another problem with Verilator as well: It can't simulate encrypted/proprietary stuff.
<ZipCPU> Perhaps that makes it the ideal OpenSource solution, since it forces designs to have their sources available in order to build.
<ZipCPU> Morn_: I've also just recently added multiple clock test bench support to Verilator as well ...
<Morn_> yeah i never encountered any encrypted verylog or whatever
<Morn_> interesting
<Morn_> so you are programming on verilator?
<ZipCPU> All of my programming is done with Verilator, yes.
<Morn_> i mean you are working on the verilator source code?
<ZipCPU> No.
<Morn_> ok ^_^
<Morn_> well but it is good to hear that verilator seems to work so well
<ZipCPU> The multiple-clock test bench support I referenced was an automatic Verilator test bench builder, built in C++.
<ZipCPU> Yes, I still need to build some proper documentation.
<ZipCPU> However, I'll probably start by simply blogging about how to add simple peripherals to an autofpga project.
<Morn_> wow you have a lot of interesting stuff on your github
<ZipCPU> Don't forget the blog as well: zipcpu.com
<Morn_> so you use the verilator for simulation and the xilinx tools for synthesis?
<ZipCPU> Basically, I use the vendor supplied tools for synthesis for all but my iCE40 projects.
<pie_> compile vhdl to verilog! :P
<Morn_> pie, also a nice idea :D
<pie_> probably a terrible idea for debugging but i wouldnt know
<ZipCPU> pie_: I'm told that others have tried, but that the two aren't nearly as translatable as one might like.
<pie_> ZipCPU, what do you mean by encrypted simulation??
<Morn_> I hoped that I could use the Xilinx simulator for my project, but it crashes all the time
<ZipCPU> pie_: Sorry, that sounds pretty confusing, doesn't it?
<ZipCPU> What I mean is ... when a vendor provides an encrypted piece of "IP" ... how do you go about simulating it?
<ZipCPU> Morn_: What is your project?
<pie_> i mean how do they use encrypted ip to begin with
<pie_> needs to be decrypted first?
<Morn_> currently i am just trying to get the pulpino microcontroller working
<ZipCPU> pie_: I guess. Somehow Xilinx handles that ... I don't know the details.
<pie_> ok that makes more sense
<Morn_> pie: i think some commercial HDL tools have something to "encrypt" IP blocks somehow so that users cannot see their source code anymore
<pie_> i was like, homomiorphic encryption isnt a practical thing yet xD
indy has quit [Ping timeout: 276 seconds]
<Morn_> what is also common practice is to distribute just obfuscated source code so people can use it but cannot understand how it works
<pie_> well sure but thats different
<Morn_> i think people should just open source everything :D
<jn__> pie_: heard you can extract the excryption keys from vendor tools…
<pie_> jn__, yeah i figured :P
<Morn_> but that still makes it illegal under some US law propbably
<pie_> i mean its gotta be in there somewhere if theres some kind of vendor tool lock-in at leasrt or osmething
<ZipCPU> Morn_: In order to use Verilator as a simulator, you basically require people to opensource everything.
<Morn_> well obfuscated HDL will also work
<Morn_> i guess
<pie_> as long as you have code obfuscated or not it should work id guess?
<ZipCPU> Sure ... it works ... until it doesn't.
<pie_> as long as its standard
indy has joined ##openfpga
<ZipCPU> Ah, here's the quote I was looking for: "Closed source CPUs are the worst of two worlds. You have to worry about resource usage and timing without being able to analyze it."
<Morn_> Well thanks for RISC-V maybe we all have open source CPUs in our computers in a few years
<ZipCPU> At least in our FPGAs ... ZipCPU!
<Morn_> ZipCPU o.O
<ZipCPU> :D
<Morn_> ah you made an own cpu architecture?
<ZipCPU> Yes.
<Morn_> cool :D
<ZipCPU> :D
<Morn_> I always wanted to make a CPU out of those tiny logic chips that only have a AND gate or a register in it
<Morn_> so i made up a CPU architecture
<Morn_> which i figured was easy to build
<ZipCPU> If you intend to do the same within an FPGA, you might want to browse the zipcpu.com blog.
<ZipCPU> I've been putting some time and effort into discussing how to _debug_ FPGA-based CPU's.
<Morn_> and i wrote a simulator for it.. and then i figured out it was very horrible to program... it took like 20 instructions to push something on the stack
<Morn_> hmm interesting
<Morn_> have you tried out any RISC-V cpu?
<ZipCPU> No.
<ZipCPU> I've read a lot about it, but never tried it.
<Morn_> you should. it is really good and maybe better than ARM even?
<ZipCPU> Perhaps.
<Morn_> ZipCPU: One thing I really wonder: Your website looks very non-commercial but it seems like you are a company. Are you making money with all the digital design work you do?
<ZipCPU> Some.
<ZipCPU> Not nearly enough to pay for the effort I'm putting into it though.
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Morn_> okay ;)
enriq has joined ##openfpga
<ZipCPU> I do work on it full-time, though, when no one else has purchased my time.
<Morn_> that is pretty neat
<ZipCPU> I think it would be even neater if you found some of my stuff valuable. ;P
<Morn_> i mean you could probably also work full-time for any of those big or small chip companies
<ZipCPU> Perhaps. I have two things getting in the way.
<ZipCPU> 1. I insist on being my own small company entity, and
<ZipCPU> 2. ... I don't know anyone at any of those companies who might want my services.
enriq has quit [Client Quit]
<Morn_> hmm yeah
<ZipCPU> Perhaps it's just going to be a matter of time.
<ZipCPU> I know many of them have already noticed my blog.
<Morn_> pretty impressive all the work you have done there :)
enriq has joined ##openfpga
<ZipCPU> Thanks!
<ZipCPU> Feel free to try it out!
<Morn_> ok :D
<Morn_> i am going to graduate soon from university and also want to do some digital design or so then
<ZipCPU> Are you studying digital design in school?
<Morn_> but i feel like working for a company and letting them sell your code under restrictive licenses is like selling your soul
<Morn_> sort of, computer engineering
<ZipCPU> And ... what level of degree are you working on?
<Morn_> master in computer engineering
<ZipCPU> My master's degree was in computer engineering as well.
<Morn_> yeah that makes sense ;)
<ZipCPU> Of course, you can read about all of that on the blog site as well.
<Morn_> you even have a gcc for your own cpu? :o
<ZipCPU> It's just a back end, I wasn't the author of GCC.
<ZipCPU> It's not nearly as hard as it sounds, although it did take me several months of work.
<Morn_> wow nice
<Morn_> after i graduate i also want to do that kind of stuff but i doubt i will make a living with it.. well whatever XD
<ZipCPU> Go where God leads.
<Morn_> okay ;)
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
azonenberg_work has joined ##openfpga
<ZipCPU> Morn_: One other item I'd like to bring up ... it's interactions with students, such as yourself, that often become the motivations for the blog articles I've written.
<ZipCPU> Feel free to share regarding any digital design learning/courses you've done, any thing that you have been confused by or that you don't think has been covered very well.
<Morn_> okay :) if i have any questions i will ask
<Morn_> thanks!
<openfpga-github> [yosys] azonenberg pushed 8 new commits to master: https://git.io/v5BZ5
<openfpga-github> yosys/master 271e8ba Jason Lowdermilk: fix indent level
<openfpga-github> yosys/master 71d43cf Jason Lowdermilk: Merge remote-tracking branch 'upstream/master'
<openfpga-github> yosys/master 32c0f11 Jason Lowdermilk: Add support for source line tracking through synthesis phase
enriq has joined ##openfpga
<azonenberg_work> rqou: how chip specific is coolrunner2_sop?
<azonenberg_work> i.e. is it plausible to make it more generic and work on other CPLDs?
<azonenberg_work> or is it all full of coolrunner-isms
theMagnumOrange has quit [Ping timeout: 248 seconds]
<openfpga-github> [yosys] azonenberg pushed 1 new commit to master: https://git.io/v5BcP
<openfpga-github> yosys/master 55ace45 Andrew Zonenberg: Fixed typo in error message
<openfpga-github> [yosys] azonenberg created gpak-refactoring (+3 new commits): https://git.io/v5BC3
<openfpga-github> yosys/gpak-refactoring 40021d2 Andrew Zonenberg: Fixed typo in error message
<openfpga-github> yosys/gpak-refactoring fc0c7f7 Andrew Zonenberg: Added blackbox $__COUNT_ cell model
<openfpga-github> yosys/gpak-refactoring 80aaf50 Andrew Zonenberg: Refactoring: moved modules still in cells_sim to cells_sim_wip
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
enriq has joined ##openfpga
theMagnumOrange has joined ##openfpga
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
enriq has joined ##openfpga
m_w has joined ##openfpga
hobbes- has joined ##openfpga
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<openfpga-github> [yosys] azonenberg created coolrunner-techmap (+5 new commits): https://git.io/v5B41
<openfpga-github> yosys/coolrunner-techmap 6775177 Robert Ou: coolrunner2: Initial fixes for special p-terms...
<openfpga-github> yosys/coolrunner-techmap 7f08be4 Robert Ou: coolrunner2: Fix mapping of flip-flops
<openfpga-github> yosys/coolrunner-techmap ac84f47 Robert Ou: coolrunner2: Combine some for loops together
m_t has quit [Quit: Leaving]
pie_ has quit [Read error: Connection reset by peer]
pie_ has joined ##openfpga
test123456 has joined ##openfpga
pie_ has quit [Ping timeout: 240 seconds]
awygle_m has joined ##openfpga
<rqou> azonenberg_work: as of yesterday or so, coolrunner2_sop is very coolrunner-specific
<rqou> because i added special p-term handling
<azonenberg_work> Ok, just wondering
<rqou> but it's only ~100loc
<azonenberg_work> i'm totally fine with chip specific passes but things like shregs, counters, etc i try to make generic if this is reasonably plausible
<rqou> so just copypasta it for a different cpld?
<azonenberg_work> lol i guess
<azonenberg_work> Just thinking longer term for e.g. psoc how much reinventing we'll have to do
<rqou> should be relatively little on the yosys front
<rqou> xbpar needs some work
<balrog> rqou: I see the GPL stuff was pulled
<rqou> it was?
<rqou> i haven't actually checked github in a while
<rqou> backlogged/distracted as usual
<rqou> btw offtopic: i managed to get steam controller touchpads talking to replacement FW in cirque's "full processing" mode
<rqou> but the original steam controller firmware is doing something special and seems to be operating in a "raw AFE" mode that doesn't work
<azonenberg_work> rqou: your recover_adder pass does not find constant adders, correct?
<azonenberg_work> only a+b where a,b are nets in the design?
<rqou> no it does not
<azonenberg_work> Ok
<rqou> i don't actually know how to find constant adders :P
<azonenberg_work> Also, when you get a chance (not a rush but by end of today would be nice)
pie_ has joined ##openfpga
<azonenberg_work> can you make an example coolrunner bitstream (by hand) that adds two 3-bit numbers, then decompile and show the resulting high level output?
<rqou> ok
<azonenberg_work> i'm doing most of my demos by hand in greenpak but i want coolrunner examples to show side by side when possible
<rqou> no carry in/out?
<azonenberg_work> Nope
<azonenberg_work> Just reg[2:0] foo = bar + baz;
<azonenberg_work> wire[2:0] *
<azonenberg_work> cant type :p
<rqou> (which work somewhat worse btw)
digshadow has quit [Ping timeout: 255 seconds]
test123456 has quit [Remote host closed the connection]
MrY has joined ##openfpga
MrY has quit [Ping timeout: 240 seconds]
test123456 has joined ##openfpga
test123456 has quit [Ping timeout: 240 seconds]
test123456 has joined ##openfpga
test123456 has quit [Client Quit]
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
digshadow has joined ##openfpga
X-Scale has joined ##openfpga
Hootch has quit [Quit: Leaving]
m_t has joined ##openfpga
enriq has joined ##openfpga
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
enriq has joined ##openfpga
<rqou> very very naive ripple-carry adder that probably isn't optimally packed
<rqou> unless you want me to go kogge-stone this? :P
<rqou> (which probably isn't optimal for PLAs anyways)
<rqou> also warning: not actually tested on hardware :P
m_t_ has joined ##openfpga
<pie_> warning: nothing is tested
m_t has quit [Ping timeout: 240 seconds]
digshadow has quit [Quit: Leaving.]
<azonenberg_work> rqou: as long as it extracts OK i'm good :)
<rqou> it does extract OK
<rqou> with our extractor, not clifford's
<rqou> i _finally_ got around to testing clifford's extractor, and it... doesn't work
<azonenberg_work> lol
<azonenberg_work> Still broken?
<rqou> alright, this time i'm going to go investigate WHY it's broken
<rqou> instead of not having time to go look :P
<azonenberg_work> lol
m_t_ has quit [Ping timeout: 240 seconds]
m_t has joined ##openfpga
<pie_> azonenberg_work, is there a way to report security holes in us government websites without being anal raped?
<rqou> us government websites? security? hah!
Marex has quit [Ping timeout: 248 seconds]
<qu1j0t3> pie_: ask @laurilove, gary mckinnon about that
Marex has joined ##openfpga
<rqou> oooh azonenberg_work i think i know why clifford's extract pass doesn't work
<azonenberg_work> oh?
<pie_> inb4 they just remove the site and dont replace it with anything because its just a shitty administrative county site :/
<rqou> er, maybe not
<pie_> rqou, right :/
* pie_ mumbles about office of personnel hack
<openfpga-github> [yosys] azonenberg pushed 1 new commit to master: https://git.io/v5RvA
<openfpga-github> yosys/master aa8d8fe Andrew Zonenberg: Removed duplicated source file in Makefile
<pie_> qu1j0t3, i dont use twitter
<azonenberg_work> pie_: what class of bug is it? whats the impact? what data would be exposed if it was exploited?
<pie_> i didnt dare poke it much since im actually using the service, its at least a data leak, fields dont seem to be verified with regard to you actually owning that entry and are incremental, so you can pick an arbitrary appropriate number and get some data leakage on other people's stuff
<azonenberg_work> lol welp
<pie_> not sure what kind of data you can get but going by how ubiquitous the problem is on the site (i tried on 2 pageS), CCs could be exposed i guess
<azonenberg_work> Yeah that should probably get reported
<pie_> its a pretty obscure site but now i am exceedingly uncomfortable using it xD
<azonenberg_work> Lol
<pie_> its a county site
<pie_> and it looks terrible and urls end in .cfm
m_t has quit [Quit: Leaving]
<balrog> Adobe ColdFusion
<azonenberg_work> lol
<balrog> "In March 2013, a known issue affecting ColdFusion 8, 9 and 10 left the National Vulnerability Database open to attack."
<pie_> lol
<pie_> balrog, weakest link tho :P
<pie_> so yeah i was like hm what id i change that id fiel-OH FUCK
<rqou> azonenberg_work: potential long term project: an AIG manipulating tool with code that can actually be understood :P
enriq has quit [Read error: Connection reset by peer]
<rqou> or is that too much NIH?
enriq has joined ##openfpga
<pie_> nih is always good when you are better :D
<pie_> 'cept like, dont overburden etc etc
<rqou> the problem is that abc actually works
<pie_> whats AIG?
<rqou> and-inverter graph
<rqou> the "new" hotness in logic optimization
<pie_> ohh
<pie_> soo NANDs? xD
<azonenberg_work> separate ands and inverters
<pie_> ok ok im guessing its not just the output or not all th time
<azonenberg_work> not merged
<pie_> i suppose i should look it up
<azonenberg_work> and it's more of an IR i guess?
<pie_> i see
<pie_> "pretty dumb web vul tho, no geek cred :("
<pie_> whoops
<rqou> although i believe pointfree might be working on an AIG/MIG tool, except probably in forth
<pie_> * Circuits composed of simple gates, including AIGs, are an "ancient" research topic. The interest in AIGs started in the late 1950s[1] and continued in the 1970s when various local transformations have been developed.
<pie_> back and FORTH
<rqou> is that alanmi's paper?
* pie_ shows himself out
<rqou> but seriously, azonenberg_work: at what point do you think it'd be appropriate for me to bug alanmi about xor gates?
<azonenberg_work> Talk later, about ot head out
<pie_> o/
Morn_ has quit [Quit: ZNC - http://znc.in]
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
enriq has joined ##openfpga
Morn_ has joined ##openfpga
azonenberg_work has quit [Ping timeout: 240 seconds]
pie_ has quit [Ping timeout: 240 seconds]
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
whitequark has quit [Quit: leaving]
enriq has joined ##openfpga
brane2 has joined ##openfpga
<brane2> hi folks...
<pointfree> I was using quantifiers in those BDD's, so I guess I was effectively using AOIG's.
<brane2> one question - silego GreenPAK thingies...
<pointfree> Quantifiers keep the BDD size from exploding.
<brane2> anyone here using those ?
<pointfree> brane2: Yes.
<rqou> um, azonenberg obviously? :P
<brane2> so how do you rate them - useable as logic patches or is there more to them ?
<rqou> apparently the intended use case is PMICs and glue logic
<brane2> with those few OTP fuses their interconnect seems very limited...
<rqou> iirc the interconnect is a full crossbar in each "half"
<rqou> it's only very limited how to get signals between the halves
<brane2> yes, but, fore eaxmple, take counter block
<brane2> there is no way to get to individual bits
<rqou> that's correct unfortunately
<brane2> or I2C/SPI
<brane2> there is not that much you can do with it...
<brane2> also $0.5/chip is not that cheap...
<rqou> yeah, they are very limited in the number of state bits they have
<brane2> one can have very decent Lattice ECP5 for 12 of those thingies...
<rqou> sure, but an ECP5 also needs a lot more "support" circuitry
<brane2> I find them to be nice for level conversion, plus maybe one or two simple functions, but aboove that
<brane2> one very soon hits some connection snag...
<brane2> what is typical role you use them for ?
<rqou> i haven't used them extensively, but i don't think connections are the usual limitation
<rqou> i would have expected the usual limitation to be total state bits
<rqou> unfortunately i haven't really used them much, so my typical use is "help azonenberg debug"
<brane2> if it's not a secret,what is on their DVKIT board...
<brane2> they claim it can do emulation, so how does it do it- some small SRAM-based FPGA or something ?
<awygle_m> iirc the thing *can* use an external bitstream, you're just not "supposed" to. I think there's a strap pin or something
<brane2> ah, zo...
<brane2> so, when you want to emulate GPxxx, you have to have programming adapter on the devkit board and chip in it ?
<brane2> so that it would be just configured ( not programmed) and would by itself be emulator ?
<awygle_m> Check the FAQ on silego's website
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<awygle_m> Apparently in emulation mode the OTP NVM is bypassed and chip config is written directly to the SRAM buffer
<rqou> yeah, that's correct
<brane2> this means that I can't emulate just any chip with deboard- I have to actually have chips...
<brane2> good to know...
<brane2> thanks..
<rqou> depending on which configuration of devkit you buy, it comes with a small quantity of sample chips
<rqou> gp3/gp4/gp5 (iirc) all use the same devkit board, although you may need a different ZIF socket depending on the package
<brane2> I know, but I noticed they all share same main board and same housings share same clamshell adapter...
<rqou> the ZIF adapter isn't always the same
<rqou> the main board is
<brane2> so, since they have bazillion of models...
<brane2> I thought maybe I could start with one adapter for one package type ( and those 50 chips)...
enriq has joined ##openfpga
<brane2> and then with each design place emulation socket on board and play with emulation of functionality of many chips
<rqou> oh, apparently silego redid how their devkits worked
<rqou> because the old way was too confusing
<brane2> and once I nail the design, just order chips, if needed...
<rqou> i think what you need is one SLG4DVKADV and one SLG46620V-SKT
<rqou> which includes 50 chips
<brane2> i've already ordered it but SLG46621V-SKT
<rqou> uh
<brane2> and a 100 of SLG46538V - they should fit in same adapter...
<rqou> i don't think that chip is as well supported
enriq has quit [Client Quit]
<rqou> i strongly recommend getting the slg46620v because that's the primary test target
<brane2> well, now it is what it is...
<brane2> BTW what do you mean by that - "primary test target" ?
<brane2> They are SELLING these things...
<rqou> oh, i meant for our openfpga project
<brane2> So is it too much to expect them to work as declared ?
<rqou> i assumed you were going to be using our third-party verilog flow
<rqou> if you use their schematic-based tool, they all work
<brane2> ah, ok.
enriq has joined ##openfpga
<rqou> yeah, our verilog flow doesn't support the SLG46538V at all
<brane2> openfpga is IIRC all about small Lattices ( former IceCube stuff) these days, I presume ?
<rqou> um, no
<rqou> yeah, the "support" resources for these projects are all kinda a mess
<jn__> ice storm is about lattice ice40, openfpga is more general
GenTooMan has joined ##openfpga
<jn__> s/ice /ice/
<rqou> this channel is basically azonenberg's channel
<rqou> for discussing anything reasonably related to hardware hacking
<rqou> with a focus on FPGAs
<rqou> so any FPGA-related discussion is more-or-less on topic
<rqou> this is _not_ the official icestorm/yosys channel
<rqou> there is #yosys for yosys, but afaik there's no official icestorm channel
<brane2> gooogle...gooogle... so this is about GreenPak4, CoolrunnerII and PSoC5LP...
<rqou> anyways, icestorm/ice40 is occasionally used by people here
<rqou> the "azonenberg/openfpga" project primarily supports GreenPak4
<rqou> i am working on CoolrunnerII
<rqou> some other people here are working on PSoC5LP
<rqou> make sense? :P
<rqou> occasionally there will also be discussions about Xilinx RE, general RE, place-and-route algorithms, "infosec," shitposting, and politics :P :P
<brane2> :o)
<brane2> funny thing is, someone on reddit has pointed me here...
<rqou> oh?
<brane2> to which my answer was "GP4 is not really an FPGA"
<rqou> link?
<brane2> but... neither is CoolRunner,so...
<rqou> feel free to help :P
<awygle_m> I was so excited for labor day to spend like 48 hours working on my p&r system, but then PAX is also this weekend. Whoops.
<rqou> PAX?
<awygle_m> Penny Arcade eXpo
<awygle_m> It's a video game con, I bought tickets months ago
<rqou> lol vidya
<rqou> :P
<rqou> (says the guy who is wasting time haxoring the steam controller)
<awygle_m> Yeah I was gonna say, which of us is theorizing about NES flash carts in the channel?
<awygle_m> :-P
<rqou> hey, i wrote azonenberg's adder this morning
<rqou> that was useful! :P
<awygle_m> Yeah obviously you're way ahead of me on the "walk the walk" score lol
<awygle_m> Speaking of, back to work....
<rqou> work work or openfpga work?
<awygle_m> Work work :-( no time for openfpga work until probably Monday
<awygle_m> Although I might get some done sat or sun evening
<awygle_m> I have a plan and have actually written some code so I'm super motivated right now but also super busy :-/
<rqou> have you managed to understand the ice40 layout?
<rqou> can you explain it to me? :P :P
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
enriq has joined ##openfpga
<awygle_m> But we have high level bitstreams now!
<rqou> not anymore :P
<awygle_m> More seriously, I'm pretty sure I understand it now, I have some tests and things to do to prove that, and I'm mostly focused on placement for now because that seems the more interesting problem (rather than routing)
<rqou> yeah
<awygle_m> Yak Barber awygle wants to write an ice40 emulator like the cool kids with their coolrunner
<rqou> in verilog? or in C?
<awygle_m> Verilog
<rqou> going to need a huge fpga to synthesize that into :P
<awygle_m> A la azonenberg's "coolrunner on an artix" thing
<rqou> can you first do a ice40->json converter?
<awygle_m> I don't know how true that is tbh. Architecture will map much better than crossbar does. I could probably do the 384 at least
<awygle_m> ice40->json meaning what?
<rqou> ice40 bitstream back to a yosys netlist
<rqou> for the un-techmapping/RE work
<awygle_m> Can't you just read_blif?
<rqou> the problem is that bitstreams require a ridiculous amount of state bits
<awygle_m> Oh I see nvm
<rqou> you could read_blif if you could turn a .bin into a .blif
<rqou> which i don't believe you can do?
<awygle_m> Yeah I got that a bit late lol
<rqou> wait
<rqou> there's icebox_vlog
<awygle_m> Yeah
<rqou> i'm an idiot
<rqou> wow it's slow
azonenberg_work has joined ##openfpga
<rqou> azonenberg_work: i just realized that i'm an idiot, and we already have ice40 de-techmapping
<rqou> it's called icebox_vlog.py :P
<azonenberg_work> lol
<azonenberg_work> it goes to yosys json?
<azonenberg_work> or verilog, which works just as well i guess
<rqou> it goes to verilog
<rqou> but it's really slow
<rqou> azonenberg_work: want to give this a try? https://gist.github.com/rqou/514f234d477585e4519c802ef3317238
<rqou> contains your uart, an address decoder, and a rom
<azonenberg_work> Ooh
<azonenberg_work> This was an ice40 design?
<rqou> yeah
pie_ has joined ##openfpga
<azonenberg_work> That... is gonna need some work
<azonenberg_work> xdot still hasnt loaded the graph :P
<azonenberg_work> But more test data is always nice
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<azonenberg_work> Lol, my desynthesis turned 2900 lines of verilog into 3400 :p
<azonenberg_work> not sure this is an improvement :p
<azonenberg_work> But a good chunk of that is from adding (* src *) to everything
azonenberg_work has quit [Ping timeout: 252 seconds]
azonenberg_work has joined ##openfpga
<azonenberg_work> rqou: btw recover_reduce is just a little bit verbose :p
<azonenberg_work> any chance you could tone down the output for cells that it doesn't turn into reductions?
<azonenberg_work> Working on cell $abc$4820$auto$blifparse.cc:346:parse_blif$5214...
<azonenberg_work> $abc$4820$auto$blifparse.cc:346:parse_blif$5214
<azonenberg_work> Cells:
<azonenberg_work> Head cell is $abc$4820$auto$blifparse.cc:346:parse_blif$5214
<azonenberg_work> that repeated for every cell in the design is a bit much :p
<pointfree> I just remembered the PSoC 5LP UDB array and DSI are engulfed by the peripheral bitband-alias region.
<pointfree> I should consider using it.
eduardo_ has joined ##openfpga
awygle_m has quit [Remote host closed the connection]
awygle_m has joined ##openfpga
<azonenberg_work> Plane is boarding, back later
eduardo__ has quit [Ping timeout: 248 seconds]
azonenberg_work has quit [Ping timeout: 252 seconds]
digshadow has joined ##openfpga
<rqou> pointfree: do you have any interest at all in making a "traditional" yosys flow work for psoc? (rather than a forth/on-cpu flow?)
awygle_m_ has joined ##openfpga
awygle_m has quit [Read error: Connection reset by peer]
<awygle_m_> rqou: what's your least unfavorite build system? :-P
<rqou> the "f*ck it" build system
<rqou> a bash file that just runs every build command manually
<rqou> second least unfavorite is plain make
<rqou> i have my personal makefile template that unfortunately isn't open-source or documented
<rqou> it's an unholy amalgamation/rewrite vaguely based on a combination of some examples from the o'reilly makefile book and devkitPro's build system
<awygle_m_> Mk
<rqou> probably doesn't help you very much :P
<rqou> neither of these are things you can "just adopt"
<awygle_m_> Lol well it confirms my "make is the least bad" leanings
<awygle_m_> I share your distaste for all existing build systems if not your apparent scorn :-P
<rqou> it's just that when i'm hacking on something i just want the build system to get out of my way
<rqou> because usually the build system is not the thing i wanted to hack on
<pointfree> rqou: I have some interest in both. I consider those two things to be different projects. A yosys flow for the PSoC is interesting because it makes designs portable between different fpgas/cplds. At some point I would like to have some way to get designs off the PSoC and onto a bigger device. Why do you ask?
<rqou> i'm just asking because we're making some decent progress getting the coolrunner stuff more working
<rqou> so it'd be good to see how reusable the code i've written is