jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jevinskie has joined #yosys
_whitelogger has joined #yosys
pie_ has quit [Ping timeout: 250 seconds]
_whitelogger has quit [Ping timeout: 250 seconds]
_whitelogger has joined #yosys
seldridge0 has quit [Ping timeout: 250 seconds]
pie_ has joined #yosys
<hedgeberg>
cr1901_modern fair enough. Any idea what it would take for someone with uh, all of 0 compiler experience to implement the enum token?
<hedgeberg>
also, while I'm at it, what's the status of supporting any of the Xilinx 7 series chips in nextpnr?
<cr1901_modern>
hedgeberg: My recommendation would be to read chapters 2 and 3 of Appel's Modern Compiler Implementation in C. It explains the theory behind lex and yacc so you (in principle) never have to impl it yourself.
<hedgeberg>
I remember hearing there had been some extensive RE of the bitstream format? is there anywhere I could go to see what has been done/needs to be done?
<cr1901_modern>
Or Dragon Book (which is what clifford read AIUI)
<tpb>
Title: SymbiFlow (at symbiflow.github.io)
<hedgeberg>
o, that would make sense considering its 35c3 and therefore release time.
* cr1901_modern
is currently reading the LR part of Chapter 3
<hedgeberg>
ok so I hate to be that guy, but... think I could figure it out by looking at how other tokens are handled in the compiler???
<sorear>
the branch uses a third-party (and GPL3) tool "torc" to do some of the work
<cr1901_modern>
hedgeberg: YMMV. I'm a bit too stupid to figure it out w/o reading a book :P.
<daveshah>
Yes, this basically means it uses the official databases and ISE bitgen rather than XRay
<hedgeberg>
daveshah so, its not reversed from ISE/vivado? it instead uses xilinx's own data?
<hedgeberg>
fascinating, never heard of torc before.
<daveshah>
Yes, Torc is intended for use by universities, etc for research
<daveshah>
There's a more modern equivalent RapidWright for Vivado
<hedgeberg>
are they.. supported by xilinx?? i find that surprising
<daveshah>
It shouldn't be hard to move bitstream generation to use XRay FASM once XRay has IO support
wavedrom has quit [Ping timeout: 246 seconds]
<daveshah>
I guess endorsed but not supported by Xilinx
<hedgeberg>
oooh, they have some virtex IV support. nice. maybe by the time I need to use my nice virtex IV board,it wont need to be with ISE.
jcreus has joined #yosys
<daveshah>
With Torc you still have to use ISE for bitstream gen
<hedgeberg>
oh, bleh
<hedgeberg>
at least it removes the synthesizer/pnr from the loop
<daveshah>
Until someone (mwk hopefully) does bit docs for Virtex 4 at least
rohitksingh has quit [Ping timeout: 246 seconds]
<hedgeberg>
mwk?
rohitksingh has joined #yosys
<daveshah>
He's been looking at bitstream stuff for various Xilinx parts
<hedgeberg>
ngl part of me feels like its almost better to reverse than use other people's tools, but I also know thats probably not a good way of approaching this
<hedgeberg>
so, I guess this is something I've always been curious about, whats the level of difference between the bitstream and then PnR output?
<daveshah>
The PnR output is basically text describing functionality and routing
<cr1901_modern>
For the FOSS tools, the pnr output is ascii repr of bitstream
<hedgeberg>
I'm sure its clearly more complex than im assuming, but to my unfamiliar ape brain, I'd assume the pnr output and bitstream are 1-to-1
<daveshah>
For xc7 and ecp5 the PnR output is higher level but still 1 to 1
<daveshah>
For example we describe connectivity in terms of wire names
<daveshah>
This needs to be looked up to actual bits
<hedgeberg>
yeah, its like an assembler
* cr1901_modern
wonders how much ice40 sales will take a nosedive once the series 7 bandwagon gets rolling
<hedgeberg>
I think the ice40 chips will stick around for a while
<hedgeberg>
they had a real market before OSS stuff, and they'll have a real market afterwards too
<sorear>
if everyone in this chat buys a devboard that's how many ppb of lattice's volume?
<daveshah>
I think we will keep recommending ice40 for beginners stuff for a long time too
<hedgeberg>
anyway, I guess the reason im confused is that, if you can make a pnr output file where youve enabled some small set of routes/flipflops/gates/etc, and then run bitgen on it, it should be relatively simple to document how different pnr output elements correlate to bitstream?
<daveshah>
Yes, that's exactly what I did for ecp5 and similar to what clifford did for xray
<sorear>
I have no idea why we're following the gcc approach of having an assembler instead of the modern-compiler approach of generating binaries and having a disassembler for debugging
<hedgeberg>
and has noone done it for xc7 then?
<daveshah>
They have
<sorear>
the xc7 work doesn't include I/O cells yet, so it's difficult to demo
<daveshah>
It's just a bit rough around the edges and not the best place to start developing a PnR tool with right now
<daveshah>
And that
<daveshah>
You can work around the IO issue with partial reconfig, but when writing a PnR tool you want as few things as possible to debug
<hedgeberg>
sorear the use of an intermediate language etc honestly makes /more/ sense re: hdl to me than it does re: machine code
<hedgeberg>
yeah
<daveshah>
In particular Eddie was very familiar with Torc and XDL because of Verilog to bitstream in the past
<daveshah>
So it was a natural place to start
<hedgeberg>
like, in hdl you extract your state machines and your netlist, which is the perfect use for an intermediate representation imo
<hedgeberg>
also, what compilers come with decompilers? because that sounds amazing. I'd love to not have to use IDA anymore
<daveshah>
RTL ILs, the biggest thread in open source EDA, locked after 1000000 heated replies
<hedgeberg>
oh so I'm not the only one with A Strong Opinion(tm) on this subject
<tpb>
Title: Lowlevel LLVM-like language as HDL middle layer · Issue #19 · SymbiFlow/ideas · GitHub (at github.com)
<daveshah>
Presented without comment
<cr1901_modern>
The OP is also a piece of work
<hedgeberg>
anyway, daveshah now that im a bit more up to date, ill prolly try to mess around with implementing enum into yosys over the next couple of days. assuming i somehow manage to make it work, i guess the main question then is where would it be best to throw in some work on xc7?
<hedgeberg>
working on reversing io cells?
<daveshah>
You could speak to digshadow about that?
<hedgeberg>
also yeah, cr1901_modern he seems like it tbh...
<daveshah>
He doesn't seem to be in this channel. Might be work asking in #symbiflow
<cr1901_modern>
Btw, this is still kinda true... I'm bad at removing stuff from my todoist
<hedgeberg>
pffffft dude I had forgotten about this, that was so long ago
<hedgeberg>
fwiw, offer is still open
<cr1901_modern>
ty :3
<sorear>
a Big Question which I'd like an answer to: what kind of IR is needed for a *friendly* mixed verilog/vhdl flow?
<hedgeberg>
but, yeah, i feel that :/
<sorear>
source-to-source compilers are not the answer, unless you prefer f2c over g77
<cr1901_modern>
sorear: Sadly enough, we talked about this in j-core a few months back
<hedgeberg>
sorear: idk tbh? maybe, like, some way to do large-block-netlisting?
<cr1901_modern>
the way to get j-core to work with yosys is probably to use nvc's IR, use the llvm backend to do vhdl elaboration, and then convert to verilog
<sorear>
do the EDA vendors have any emergent standard for how vhdl/verilog mixing works?
<hedgeberg>
PFFT
<hedgeberg>
absolutely not
<cr1901_modern>
I can instantiate simple VHDL IP in verilog code
<cr1901_modern>
that's the most I've ever done
<hedgeberg>
from what I can tell, xilinx/altera(rip)/cadence/etc refuse to standardize anything wherever possible
<hedgeberg>
so, I figure if anything they probably all have their own way of doing this and refuse to collaborate
<sorear>
I'm sorry, why wasn't this in #j-core ?
<cr1901_modern>
Because Jeff wasn't registered that night
<cr1901_modern>
and he was pressed for time
<hedgeberg>
what is j-core btw?
<cr1901_modern>
(#j-core only lets registered users speak)
<hedgeberg>
new to the OSS FPGA landscape, so a lot of this escapes me
<cr1901_modern>
hedgeberg: Remember superH? Dreamcast and Saturn and 32X?
<cr1901_modern>
it's a free version of that
<sorear>
cr1901_modern: how oten does this happen, any utility in my lurking #jcore?
<hedgeberg>
oooooooooooh
<hedgeberg>
gotcha
<sorear>
it's a … frustrating project to care about
<cr1901_modern>
sorear: In the past 2 years, that was the first time I've seen him on IRC
<hedgeberg>
at the risk of sounding ignorant, whats the benefit over riscv?
<sorear>
it's developed entirely behind closed doors by a team that speaks Japanese
<cr1901_modern>
(not the first time I've talked to him)
<cr1901_modern>
hedgeberg: Better insn density
<cr1901_modern>
it uses 16-bit insns
<cr1901_modern>
all the way thru. With all it's benefits and disadvantages
<sorear>
there is a version with a MMU. it is not public. the *programming documentation* for the MMU is not public. no, it's not the same as the Hitachi SH4 MMU
<hedgeberg>
ooh, neat, if not maybe a bit messy.
<hedgeberg>
sorear im so sorry for your loss
<sorear>
?
<sorear>
it's not my loss
<hedgeberg>
sorry, im bad at jokes
<cr1901_modern>
sorear: There's nothing I can do about that. All I can do is be patient, because even if it's taking a while, I still want it to succeed
<hedgeberg>
im just quipping about the fact that it sounds like a horrible project to be invested in
<cr1901_modern>
The more free CPUs the merrier
<cr1901_modern>
That would explain why I haven't seen you chat in a while tho
<sorear>
the j-core project predates riscv, and they've focused on "make a small number of socs that are nice to use" over the broader-range platform questions
<hedgeberg>
oh
<sorear>
I'm there, I just don't really speak unless spoken to
<cr1901_modern>
or I'm asking a stupid question about PIC
<hedgeberg>
that sounds nice, tbh. I can appreciate that.
<cr1901_modern>
that also seems to get your attention
<sorear>
yes
<hedgeberg>
anyway, ill prolly give a stab at implementing enum over the next couple of days, so if im here a lot and asking a lot of annoying questions, thats why, and also im very sorry
<cr1901_modern>
don't be :P
<sorear>
i'm not a j-core expert but I know more than I should about ELF legalese
<sorear>
so I can answer those
<cr1901_modern>
sorear: In any case, I brought up this convo b/c: If j-core ever runs on yosys, using nvc is the way it's likely to happen
<cr1901_modern>
and that might be the only way to get verilog and vhdl to "play nice"
<cr1901_modern>
(in FOSS land)
<sorear>
sh is kinda similar to thumb1; the cost of the fixed 16-bit encoding is more instructions in common cases than arm32, because you can't use any register for any inptu and output
<hedgeberg>
that or make some completely new intermediate netlisting tool that can allow for abstract modules and link them together later?
<hedgeberg>
"link", i guess, since its very much not like linking in the software sense?
<hedgeberg>
idk if that sentence made sense at all i need coffee
<sorear>
cr1901_modern: see I would have assumed the hack answer was vhdl2vl
<cr1901_modern>
hedgeberg: Sorry it didn't make sense. But it's also 4am and I should be asleep
<sorear>
hedgeberg: the crux of my question above is "what is a module? discuss"
<cr1901_modern>
sorear: vhdl2vl isn't free I don't think?
<cr1901_modern>
Oh, I thought you were abbreviating vhdl2verilog
<cr1901_modern>
in any case, I know that tool now
<cr1901_modern>
j-core is too complex for it. nvc is the only free vhdl compiler that can handle j-core
<cr1901_modern>
and since I don't want to write a front end
<cr1901_modern>
I proposed bastardizing nvc to generate verilog
<hedgeberg>
i should go to bed too, fwiw, but i have a headache so going to sleep would actually suck more /with/ coffee than without
<hedgeberg>
no i got that backwards
<cr1901_modern>
(nvc's parser is 5000 lines. Handwritten.)
<hedgeberg>
i should stop trying to talk, ill be back tmrw probably o/
<cr1901_modern>
set up a bouncer :)?
<cr1901_modern>
or just keep your client on (like I do lol)
<hedgeberg>
meh
<hedgeberg>
yeah, thats the plan, i was jsut saying bye for good manners. im not logging off
<hedgeberg>
one day when i finish my new home server architecture, ill resume running a znc instance
<hedgeberg>
until then, meh, not on irc enough to bother
<sorear>
nvc versus ghdl? the j-core tarball includes ghdl makefile bits
<cr1901_modern>
I forgot the deal w/ ghdl
<daveshah>
There is ghdlsynth, but it only supports a small subset of functionality (less than vhdl2vl on my testing)
<cr1901_modern>
tbqh, it's probably easier to write a "competing" impl in verilog or migen and feed it to yosys lmao
<cr1901_modern>
maybe not the MMU or multicore version
<cr1901_modern>
but I don't need either of those for my use cases (use sh2 w/ litex)
* cr1901_modern
should prob go to bed for real this time and _not_ watch more anime
<sorear>
(not a reply) the only HDLs I have much knowledge of relevant to implementation are systemverilog and bluespec
<sorear>
i'd like to spend time studying (n)migen, vhdl, clash, kami, etc
<cr1901_modern>
well verilog is just boneless systemveri-
<cr1901_modern>
/me is smacked
<sorear>
IMO verilog is "what people called systemverilog prior to 2005"
<cr1901_modern>
systemverilog is "super"-verilog
<sorear>
this doesn't seem to be a case like C and C++ where WG11 continues to exist and continues to make new standards that are incompatible in new and exciting ways with what WG14 did
<sorear>
*WG14 and WG21
<cr1901_modern>
C seems to be... not updated that often?
<cr1901_modern>
I think there's a C20, but it's meh
<cr1901_modern>
And as for bluespec- not interested in Haskell, sorry
<sorear>
there was an 11 year gap between (s)v specs so whatever
<cr1901_modern>
I just don't grok it and I don't think I ever will
<sorear>
it hasn't used haskell syntax in a decade
<cr1901_modern>
I just am going by the wiki article :)
rohitksingh has quit [Ping timeout: 268 seconds]
<sorear>
although bluespec's elaboration-time semantics are basically identical to haskell 98 + MultiParameterTypeClasses + FunctionalDependencies
* cr1901_modern
knows some of those words
<cr1901_modern>
I do fully admit that it isn't an accident formal flows like SMTv2 look like pure functional languages
rohitksingh has joined #yosys
hedgeberg has quit [Ping timeout: 244 seconds]
<sorear>
in which I notice that ghdl is written in Ada
<sorear>
_fitting_ but annoying
citypw has quit [Ping timeout: 244 seconds]
hedgeberg has joined #yosys
rohitksingh has quit [Ping timeout: 244 seconds]
rohitksingh has joined #yosys
m_t has joined #yosys
maikmerten has joined #yosys
<maikmerten>
just finished watching the wonderful SymbiFlow talk from 35C3. Great presentation!
<maikmerten>
just wondering if the "hostile towards Open Source" regarding Lattice is a new (active) development or the usual (?) passive "no specs for you"
<daveshah>
Lattice are *not* hostile towards open source
<daveshah>
idek why that was mentioned
<maikmerten>
ah, great
<maikmerten>
okay, that confused me a bit
<daveshah>
yes, particularly if you've been following @ico_TC recently..
<maikmerten>
well, I've watched the risc-v softcpu contest, with Lattice actually spreading boards and the yosys toolchain *not* being discouraged
<sorear>
at the end mithro talked about some fpga vendors being hostile/neutral/supportive, but didn't name names for any category
<daveshah>
even at Xilinx there are certainly individuals who are very supportive of open source (hence rapidwright)
<sorear>
Silego/Dialog gave azonenberg bitstream documentation for the GreenPAK, which he used for yosys support a few years ago (and a separate tool "gp4par")
<sorear>
in the 90s there was a company that did gate-array ASICs layout-compatible with some Altera part, and their flow involved using Quartus to synthesize and pnr a customer design, then $company would convert the bitstream into metal masks
<sorear>
Altera sued them on the grounds that they were inciting customers to violate Altera's EULA (which only permits use to program Altera devices)
<sorear>
it's unclear how relevant this is to what we do
<maikmerten>
heh, IIRC Altera also happened to offer mask-programmed parts based on some of their FPGAs
<maikmerten>
(they don't anymore)
<nats`>
if it's like xilinx it's not mask programlmed
<nats`>
they just sell you a fpga tested with your design
<nats`>
and it's cheaper because many function can be defective but you don't care
<nats`>
(but obviously you can't use the fpga with an other design or only at your own risk)
<daveshah>
Lattice had something like this at one point too (FreedomChip)
<daveshah>
I understand this also involves some kind of soft scan chain insertion during synthesis
<sorear>
Microchip/Microsemi didn't seem especially enthusiastic about icestorm in 2016 but I have no idea what the current status is
rohitksingh has quit [Ping timeout: 250 seconds]
rohitksingh has joined #yosys
<MoeIcenowy>
sorear: the AGM FPGA chips I recently researching recommends to use Quartus to synthesis...
<MoeIcenowy>
(although the toolchain also supports to use yosys to synthesis
pie_ has quit [Ping timeout: 268 seconds]
<sorear>
I saw that on twitter (and now I see you have the same nick as the person who posted there)
vidbina has joined #yosys
<sorear>
from the nvc blog:
<sorear>
> But I have a question: why did you choose C instead of C++ ?
<sorear>
> Two reasons I suppose: [...]; the second is that I find it much easier to “get things done” in C – in C++ I waste time agonising which of N possible ways I should choose to implement something: in C I just write the code ;-).
<sorear>
WAY TOO FAMILIAR
vidbina has quit [Ping timeout: 250 seconds]
vidbina has joined #yosys
MoeIcenowy has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in]
MoeIcenowy has joined #yosys
<sorear>
ideally, we would have one high quality open source verilog + vhdl frontend which could be used for linting, event simulation, wire-level simulation, synthesis, and formal verification
<sorear>
what we have: (a) a verilog-only frontend which deliberately cuts corners (IIRC) with error messages, can be used for synthesis and formal
<sorear>
(b) verilator's frontend which does wire-level sim and linting (c) iverilog's frontend which does event simulation and linting (d) ghdl (linting and events) (e) nvc (linting and events)
maikmerten has quit [Quit: Verlassend]
dys has quit [Ping timeout: 250 seconds]
vidbina has quit [Ping timeout: 268 seconds]
vidbina has joined #yosys
citypw has joined #yosys
dys has joined #yosys
AlexDaniel has quit [Ping timeout: 245 seconds]
cdleary has joined #yosys
<cdleary>
daveshah: thanks for doing the talk on project trellis at ORConf, are things at a point where a versa dev board (with the PCIex1) is a reasonable thing to get for yosys-flow-based development? (lmk if there somewhere I should have checked instead of asking in chat? :-) tia!
m_t has quit [Remote host closed the connection]
<daveshah>
As far as readily available boards go, I'd recommend the Versa-5G or the LFE5UM5G-85F-EVN
<daveshah>
There are examples for both of these inside Trellis
jcreus has quit [Read error: Connection reset by peer]
jcreus has joined #yosys
<cdleary>
daveshah: cool, I see that now! inferring from one of these config files that it's programmed via FTDI interface like on the ice40 boards, do those expose the UART to the FPGA on those boards as well? I can't find a datasheet that shows the uart pins ATM (Ibut I'd assume so?
<MoeIcenowy>
daveshah: by the way is ECP5 programmed via JTAG or SPI?
<daveshah>
cdleary: yes, they do. The Versa connects them by default, you need to solder some 0R resistors to get it on the EVN board
<daveshah>
MoeIcenowy: it can do either, but most boards use JTAG
<MoeIcenowy>
ah okay
<MoeIcenowy>
to be honest that iCE40 can only programming via SPI seems strange ;-)
<daveshah>
I think the iCE40 was supposed to have JTAG, some of the early docs mention it
<MoeIcenowy>
and to be honest I consider the FT232H programmer still too expensive ;-)
<tpb>
Title: GitHub - mystorm-org/BlackIce-II: Software, Firmware and documentation for the myStorm BlackIce-II board (at github.com)
<MoeIcenowy>
I think it's possible to use any USB2SPI, but iceprog only supports FT232H...
<daveshah>
yeah
<cdleary>
daveshah: I was trying to see how your fuzzer did its I/O as well to observe changed bits without perturbing the dut, trawling the code is fun, but any key pointers/hints? :-)
<MoeIcenowy>
to be honest the cheapest chip I have seen on a USB2SPI board is WCH CH551G/CH552G
<daveshah>
cdleary: The fuzzing is all based on creating a large number of bitstreams, mostly using the 'ncl' post-place-and-route-design format, with Diamond and looking for the changes in the bitstream
<MoeIcenowy>
daveshah: by the way will the fuzzing be possible without tile -> bitstream position info?
<daveshah>
Yes
<MoeIcenowy>
The way to generate tilegrid in prjtrellis gives out the tile position
<daveshah>
if you can manually create, e.g. a LUT, in every tile, you should be able to work out the tile offsets more or less
<MoeIcenowy>
but in prjtang TD do not give out this info
<cdleary>
daveshah: oh I see, no need to talk to the device at all e.g. to confirm connectivity? I was thinking of it kind of like a manufacturing test where you see if bits really push from point a to point b at the end
<daveshah>
no, no hardware is involved in fuzzing
<daveshah>
connectivity uses a mixture of the tcl api and bitstream diffing
<cdleary>
daveshah: gotcha, makes sense now
<MoeIcenowy>
by the way mmicko found how to decrypt the TD database, but he doesn't dare to use data in it...
<sorear>
there is 1 NC pin on (one? several?) of the ice40 packages and there has been speculation here that it's /TRESET
<sorear>
what's TD?
<MoeIcenowy>
sorear: the tool of Anlogic FPGAs
<MoeIcenowy>
Anlogic is a Chinese FPGA company
xerpi has joined #yosys
vidbina has quit [Ping timeout: 260 seconds]
kraiskil has joined #yosys
citypw has quit [Ping timeout: 240 seconds]
vidbina has joined #yosys
seldridge0 has joined #yosys
kraiskil has quit [Read error: Connection reset by peer]
vidbina has quit [Ping timeout: 272 seconds]
mjoldfield has quit [Read error: Connection reset by peer]
mjoldfield has joined #yosys
kraiskil has joined #yosys
tpw_rules has joined #yosys
<tpw_rules>
hey all. i just saw mithro's talk about symbiyosis and am interested in working with that project. i'm more familiar with altera devices so maybe i could work on them somehow? is he around here much?
<daveshah>
mithro is here, but for that kind of stuff you might be better off asking on #symbiflow
<tpw_rules>
oh ok, i didn't see that channel in the talk. thank you
<sorear>
have you talked to rqou yet?
lutsabound has joined #yosys
<tpw_rules>
no
<sorear>
(did some work on MAX V)
<sorear>
(is at 35c3 rn)
<rqou>
uh, hi
<rqou>
if you're at 35c3, you can call me at 8838
<tpw_rules>
no, i'm not
<tpw_rules>
my only interaction so far has been twitter rumors and the talks
<tpw_rules>
i have not so much intelligence but lots of computers and time
<qu1j0t3>
haha, i have little intelligence or time, but plenty of computers
<tpw_rules>
well i'll probably come back when the c3 business has died down a little. i would be interested in talking to rqou later
<sorear>
not counting cache misses, probably around there, maybe 1/0.9
<sorear>
I don't have a great feel for the fraction of fun instructions like postincremnt
<sorear>
this spreadsheet is suprisingly comprehensible
<sorear>
concerned by the PC = INC / HOLD column though
<cr1901_modern>
vexriscv currently does run on litex, but at present there's issues with wishbone conversion layer. Minimum 1193 logic cells is nice though (compared to ~1500 for anything litex uses for up5k right now).
<sorear>
*puts 2 and 2 together* I am skeptical j-core will fit
<sorear>
their target board is a 9K LUT6 s6, and it probably hasn't come into contact with ice40's "no distributed RAM" quirk
<cr1901_modern>
Well, I can still humor a competing impl :P
maikmerten has quit [Remote host closed the connection]
kraiskil has quit [Read error: Connection reset by peer]
mjoldfield has quit [Read error: Connection reset by peer]
mjoldfield has joined #yosys
freemint has joined #yosys
<sorear>
o/
<sorear>
(see topic if you're unclear on what this is)
vidbina has quit [Ping timeout: 252 seconds]
vidbina has joined #yosys
vidbina has quit [Ping timeout: 252 seconds]
rohitksingh has quit [Ping timeout: 246 seconds]
vidbina has joined #yosys
xerpi has quit [Ping timeout: 244 seconds]
arnd has joined #yosys
xerpi has joined #yosys
vidbina has quit [Ping timeout: 250 seconds]
vidbina has joined #yosys
kraiskil has joined #yosys
kraiskil_ has joined #yosys
kraiskil has quit [Ping timeout: 250 seconds]
mjacob has joined #yosys
seldridge0 has quit [Quit: WeeChat 1.4]
kraiskil__ has joined #yosys
kraiskil_ has quit [Ping timeout: 250 seconds]
kraiskil__ has quit [Ping timeout: 250 seconds]
wavedrom has joined #yosys
<ZipCPU>
sorear: What's wrong with a S6/LX9? It can be done if you use your resources wisely. I managed to put a multi-tasking O/S on one of those even.
kraiskil__ has joined #yosys
<sorear>
ZipCPU: nothing. cr1901_modern wants to take a design that's proven on xc6slx9 and run it on ice40up5k, but the latter is about a third the size
<ZipCPU>
Ooohhh .... okay. That makes more sense of the conversation
<sorear>
(i'm assuming s6 is also a LUT6 family and applying the 1.4x fudge factor)
<cr1901_modern>
sorear: I'm pretty sure that's the whole soc though, not just the CPU core
<ZipCPU>
One of the tricks to getting the S6SoC I built running was being *VERY* judicious with how the peripherals were built ..
xerpi has quit [Remote host closed the connection]
xerpi has joined #yosys
pie_ has joined #yosys
pie_ has quit [Remote host closed the connection]
pie_ has joined #yosys
pie_ has quit [Read error: Connection reset by peer]