nelgau_ has quit [Remote host closed the connection]
gsmecher has quit [Ping timeout: 240 seconds]
bl0x_ has quit [Ping timeout: 268 seconds]
bl0x_ has joined #yosys
nelgau_ has joined #yosys
nelgau_ has quit [Ping timeout: 256 seconds]
nelgau_ has joined #yosys
nelgau_ has quit [Remote host closed the connection]
sagar_acharya has joined #yosys
<sagar_acharya>
Hello folks. So I've been postponing working on picosoc since I don't understand the nomenclature.
nelgau_ has joined #yosys
<sagar_acharya>
What I want is control signals, input and output.
<sagar_acharya>
So I want to know, where can I store instructions? What I want to run is shell, and store some programs in memory.
<sagar_acharya>
I want something like, which control signal or signals would put forth instructions from memory on processor and where would I get output?
<sagar_acharya>
I would take care of vga and ps2. That's not a concern. The concern is I see no documentation on control signals in picorv or picosoc
<sagar_acharya>
I come from software areas so sequential execution of instructions is intuitive for me. The most difficult issue I find in HDL is that of control of execution of commands.
nelgau_ has quit [Remote host closed the connection]
nelgau_ has joined #yosys
nelgau_ has quit [Ping timeout: 240 seconds]
sagar_acharya has quit [Quit: Leaving]
FabM has joined #yosys
FabM has joined #yosys
FabM has quit [Changing host]
<Sarayan>
HDL has fully parallel and not at all sequential
<tnt>
Sarayan: tbh sounds like you're trying something that's way above your current skill level ... you need to start with the basics of understanding digital design.
<tnt>
Argh, I meant sagar_acharya
<tnt>
but since he disconnected the 's' <tab> autocompleted the wrong name.
diadatp has quit [Quit: Client limit exceeded: 20000]
<mwk>
so, I just beefed up memory_bram with some backports of functionality from the new memory inference branch; long story short, having initial values and/or sync/async resets on the memory read port register no longer prevents block RAM recognition
<tnt>
That introduces a mismatch between what's described and what get synthesized if the hw doesn't have support for that though.
<mwk>
tnt: it inserts soft logic that emulates whatever functionality is not natively available
<tnt>
Ah I see ok.
<mwk>
(actually the current version always inserts the emulation soft logic; actual native support will only be available with the new pass when it lands, I don't really want to backport *that*)
Guest30 has joined #yosys
<mwk>
(given that the emulation cost is basically one row of muxes, I don't see it pressing enough to delay the new pass even more)
<somlo>
is PDF (via LaTeX) still the "canonical" way to build the yosys manual, or is there a more preferred alternative I should be considering (e.g., for distro packaging purposes)?
<mwk>
somlo: there is some new rst-based documentation in the works, but for now the PDF manual is the only usable thing
uis has quit [Ping timeout: 256 seconds]
uis has joined #yosys
uis has quit [Client Quit]
vidbina has joined #yosys
<Guest30>
Hello. Can someone share some bits about the status of MachXO2 in yosys/nextpnr/prjtrellis? I haven't seen any news about it anywhere except for the message on twitter from Feb 2021..
Guest30 has quit [Ping timeout: 256 seconds]
FabM has quit [Ping timeout: 250 seconds]
<cr1901>
It's only been 15 minutes and they already disappeared
<cr1901>
Well, I'll give them an answer if they come back
<somlo>
mwk: thanks! (then I guess I'll hold off on packaging v13 until issue #3156 is dealt with)
nelgau_ has joined #yosys
nelgau_ has quit [Ping timeout: 240 seconds]
<mwk>
somlo: FYI I just squashed 3156
vidbina has quit [Ping timeout: 256 seconds]
cr1901 has quit [Quit: Leaving]
<somlo>
mwk: cool, thanks!
cr1901 has joined #yosys
nelgau has joined #yosys
nelgau has quit [Remote host closed the connection]
nelgau has joined #yosys
nelgau has quit [Quit: Leaving...]
Guest30 has joined #yosys
<Guest30>
cr1901 sorry.. web client lost connection without telling me about that. Just saw your reply in the channel logs.
<cr1901>
Guest30: Okay, cool... and this time I saw your reply in a minute :P. MachXO2 nextpnr backend is upstream as an experimental target
<Guest30>
I'm mainly curious about MachXO2 cause I was considering a step up from iCE40 which may be too small for my needs (some rudimentary DSP... which is difficult to squeeze in without HW multipliers). And I would like to have a hand-solderable chip (TQFP). Please correct me if I'm wrong, but AFAIK the only TQFP FPGAs well supported by oss tools are
<Guest30>
iCE40? I've also seen some info about ECP5 in TQFP144 but seems no one has seen the chip itself
<cr1901>
The new Lattice family (I forget the name) supposedly has a chip in non-BGA format
<cr1901>
Anyways, MachXO2 is mildly smaller than ice40 and doesn't have hw multipliers (at least not like the ones Xilinx families have)
<cr1901>
I fix bugs in the machxo2 nextpnr/yosys backend as I and others find them, but adding new functionality to make it closer to ice40 quality has stalled a bit
<cr1901>
It's... been a bad year and doing the nextpnr port took a lot out of me, let's put it that way
<Guest30>
>_< seems I need to sleep a bit more. Just till you've mentioned it, I honestly believed that MachXO2 has HW DSP blocks. Now I've checked the datasheet and indeed there are none!
<Guest30>
cr1901 the "new Lattice family" - I guess you're talking about CrossLink-Nx? Indeed this one has QFN72 package - not a TQFP, but definitely better than BGA :-) So maybe this will be doable... and I see that it is supported by yosys/nextpnr as well