<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]
<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>
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>
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…]
<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.
<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
<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