rohitksingh has quit [Ping timeout: 250 seconds]
rohitksingh has joined ##openfpga
moho1 has joined ##openfpga
<cr1901_modern> tpw_rules: For "FPGA code golf" purposes, I've batted around 16-bit ALU RISC-V so I can fit all the GP regs into a single BRAM
<cr1901_modern> since they all tend to have 16-bit databuses
<tpw_rules> you just have two bram addresses per register?
<cr1901_modern> yup
<tpw_rules> yeah that's a sensible choice
<tpw_rules> i'm not sure what the CNFET people did, it sounds like they just arbitrarily chopped all the registers in half which is stupid
<cr1901_modern> I've even batted around using the same BRAM for GPREGs and horizontal microcode (although that likely has perf costs that make it not worth it)
<tpw_rules> i've never heard of microcode with a dimension to it
<cr1901_modern> horizontal == the data outputs of the microcode have little to no logic before attaching to functional units
<whitequark> cr1901_modern: i thought about using that for my 8051 core
<tpw_rules> ah okay
<cr1901_modern> whitequark: The shared GPREG/microcode approach? brouhaha used it for his RISCV contest entry. But that's (by his own admission) too slow, and I'm unsure how fast I can make a design where >>
<cr1901_modern> running the microcode program and storing to registers are mutually exclusive operations
<whitequark> cr1901_modern: so the 8051 has 256 instructions
<whitequark> i kinda hoped to use 1 BRAM for microcode
<whitequark> of course, half of those are basically all the same in the same row
<whitequark> so i could stuff the entire IRAM there in theory
<whitequark> but i think it wasn't worth it
<cr1901_modern> in my RISCV design, I abstracted away all the ALU insns (or most of them) so they all run the same microcode program and opcode decoding is used to choose the correct ALU op. It's a fun balancing game between BRAM and using your limited LUTs.
<cr1901_modern> Unfortunately, I got fed up writing a ucode assembler so I shelved the project for now
<whitequark> i'd just write it in python with ... gasp ... functions
<whitequark> or in excel.
<cr1901_modern> Where have I seen that approach before?
<cr1901_modern> Either Boneless or my RISCV core will be fine for my purposes for "smol core", but only one of those is actually in a functional state (and thus I have no urgent need to finish mine).
<sorear> I’m just a pedant who would rather see “RISC-V inspired 16 bit architecture” than “16-bit RISC-V”
<tpw_rules> it sounds like it has the same decoder tho?
<tpw_rules> like it's big daddy risc-v, they just couldn't afford half of the alu or register file
<cr1901_modern> big daddy?
<tpw_rules> as opposed to some reworked inspired ISA
<tpw_rules> idk. their phrasing is ambiguous. sorear is there more info? do i need to actually read the paper
emeb_mac has left ##openfpga [##openfpga]
<sorear> sorry to say I just read a press article
<bubble_buster> what's a good usb-jtag host adapter? like I just want to be able to send load IR/DR commands and get TDO response back, seems to be a very generic, standard operation but most products seem to be specific to a certain vendor/product line, not generic, so I assume they don't provide these basic commands
<whitequark> anything that can run SVF files can do that
lutsabound has quit [Quit: Connection closed for inactivity]
Jybz has joined ##openfpga
<bubble_buster> hmm... bus pirate seems like a good one?
<bubble_buster> or hmm I found this other similar product but they want me to sign up for an email list to be notified when it's available
<bubble_buster> ;)
<cr1901_modern> libxsvf can be made to work with an FTDI breakout board if using FTDI isn't an issue for you
<bubble_buster> like this?
<cr1901_modern> Yea, that breaks out all the right pins... you need d0-d4 for mpsse JTAG IIRC
<cr1901_modern> Then you compile this:
<cr1901_modern> then you have something that can load USB->JTAG
<bubble_buster> nice thanks
<cr1901_modern> I'm not 100% sure the pin mapping using the above code... it;s been quite a while since I used it myself
<bubble_buster> would FTDI being an issue just be because of ? or is there something else to be concerned about
<cr1901_modern> Yes, that's what I'm referring to :)
<cr1901_modern> It's still a really easy way to get USB on your hardware design tho.
<whitequark> bubble_buster: they're also buggy
<whitequark> but if you don't write the drivers it's probably ok
zng has quit [Quit: ZNC 1.7.2 -]
zng has joined ##openfpga
<azonenberg> bubble_buster: real FTDI works well and is also fairly widely supported by different tools
<azonenberg> Just buy actual ones and not fakes :p
<azonenberg> but all the popular usb-uart chips have had problems with counterfeits
<azonenberg> some folks making a con badge a few days ago got bit by fake cp2102's
rohitksingh has quit [Ping timeout: 264 seconds]
Bob_Dole has joined ##openfpga
Asu has joined ##openfpga
Asu has quit [Read error: Connection reset by peer]
Asu has joined ##openfpga
adamgreig has joined ##openfpga
OmniMancer has joined ##openfpga
<ZirconiumX> <--- wiring in schematics is overrated
thehurley3[m] has quit [Remote host closed the connection]
scream has quit [Write error: Connection reset by peer]
indefini[m] has quit [Remote host closed the connection]
henriknj has quit [Read error: Connection reset by peer]
swedishhat[m] has quit [Read error: Connection reset by peer]
jfng has quit [Write error: Connection reset by peer]
xobs has quit [Remote host closed the connection]
nrossi has quit [Remote host closed the connection]
<sensille> aren't most schematics that way nowadays?
<ZirconiumX> I've seen a lot of raging wars about "air wires"
<ZirconiumX> I think good labelling here communicates the data path better than actual wiring could
<sensille> but the graphical element is not helpful
<sensille> a textual description would even be easier
<sensille> hm, can i just write netlists as input for kicad? would save a lot of work
<ZirconiumX> How do you mean? Sure, I could produce a table of outputs, but I don't think that helps much
<ZirconiumX> KiCad does have a netlist format, but it's s-exp based
nrossi has joined ##openfpga
<sensille> i'm about to draw my first schematics in decades, so i really ask myself if it's really worth the effort or if just having a textual representation of the ciruit would be enough or even better
<ZirconiumX> I think the schematics would help everybody else
<ZirconiumX> whitequark: If you pass 3 to a Boneless decode_imm_al(), is the result undefined or unpredictable?
<ZirconiumX> Undefined seems saner to me
<zignig> you can covert python to kicad netlists.
<ZirconiumX> Skidl is part of the Verilog -> 7400 IC flow
<ZirconiumX> Unfortunately the script needs a fair bit of improvement
<sensille> zignig: thanks
<zignig> ZirconiumX: they all do :)
<zignig> mine included.
<zignig> sensille: np
<ZirconiumX> Because pin swapping is necessary to get good results
<sensille> ZirconiumX: the skidl-script or the rest of the flow?
<ZirconiumX> sensille: The script that calls skidl, yeah
<ZirconiumX> In the end I gave up and am redoing it all in a KiCad schematic
<sensille> -> 7400 sound ... archaic
<ZirconiumX> Oh it is :P
<sensille> 7400 or 74xx?
<ZirconiumX> 74xx
<zignig> ZirconiumX: some inspiration for you
<ZirconiumX> Not pure NAND gates :P
<ZirconiumX> zignig: Way ahead of you; I'm friends with one of the creators
<zignig> ZirconiumX: perhaps you should make each transistor by hand. Mwhahahah
<zignig> ZirconiumX: figures .... ;)
<ZirconiumX> <--- completed "PLA"
<sensille> well, the 74xx times have been fun, but i was very happy with my first pal/gal
<ZirconiumX> zignig: My trusty friend in all of this is an unmaintained front-end to a 90's program
<ZirconiumX> Logic Friday
<zignig> sweet ! I like crusty old computing. I have a Wyse slow fade orange termial that I fire up from time to time.
<ZirconiumX> I'm crusty but not *that* crusty :P
* zignig adjusts his zimmer frame in disgust.
<zignig> :PP
<zignig> It was old when I got it.
<zignig> I have been making progress on my boneless project too.
<ZirconiumX> I can show you my current schematics if you want to take a look
<ZirconiumX> It's far from completion though :P
<zignig> need to move the the warmboot and a reset line __into__ the serial port , so I can reset it when it has locked up.
<zignig> how many chips is it at the moment ?
* ZirconiumX updates their BOM spreadsheet
<ZirconiumX> 34, zignig
<ZirconiumX> Some of the chips are perhaps a little wastefully used right now though
<zignig> still cool , I can't find the link, but I remember someone making some little FPGA tiles out of logic chips , and programming them.
<ZirconiumX> Yep, I've seen it too
<zignig> slap 64kw of SRAM in it, boom , awesome board !
<zignig> ZirconiumX: that's the one.
<zignig> can you get multiple 74xx cores on a chip ?
<ZirconiumX> Define "core"
<zignig> the logic of a 74xx series chip, but multiple copies in one package.
<ZirconiumX> I mean, normal 74xx chips often come with multiple gates
<rvense> there are modern 74xx series that are extensions of old ones... >8b buffers and muxes etc
<ZirconiumX> Generally you're kinda stuck with the existing chips
<ZirconiumX> There is Widebus for things like flops etc
<rvense> and also single gates in small packages
<zignig> I saw the surface mount version, it was awesomely ugly.
<ZirconiumX> I'm going to have to use surface mount for these :P
<zignig> because 1m^2 of PCB is really pricey ?
<ZirconiumX> The boards won't be quite that big, but yeah :P
<ZirconiumX> Actually, 1m^2 is cheap; I was in the region of 10m^2 :P
<sensille> what are you building in 74xx?
<zignig> huge!! , still gigatron(ish) size would be a cool thing.
<ZirconiumX> sensille: A Boneless CPU
<ZirconiumX> zignig: Ironically if I had access to older parts I might be able to make it smaller
<zignig> , cool 16bit processor, clean and flat.
<ZirconiumX> And possibly faster, but we'll see
<ZirconiumX> zignig: It's missing a few things that might be nice, but it works well
<sensille> wow, 16 bit
<zignig> interrupts looking like a big one for me going forward.
<ZirconiumX> Interrupts, and possibly more performance
<ZirconiumX> I've been considering giving Boneless a register file
<zignig> but as an all new ISA and design it is a very nice start.
<ZirconiumX> Even though that makes window adjustment painful
<zignig> ZirconiumX: I think her quarkyness wanted to have a fully flat memory , perhaps make the whole memory space a line cache ?
<ZirconiumX> There's not much you can do to cache things
<zignig> indeed not, the v2 would run at 50Mhz , but the interals have changed heaps.
<zignig> can you use yosys/nextpnr to find what part is slowing it down ?
<ZirconiumX> Not entirely
<ZirconiumX> Nextpnr makes very little sense for me in any case
<ZirconiumX> The CPU plus memory run at ~80MHz on a Cyclone V
<zignig> yeah , it's a _insert_magic_here_ for me too.
<zignig> Oooh, ok. It just does not like ice40 atm.
<ZirconiumX> Or ECP5 apparently
<ZirconiumX> Despite those being the chips it's designed for
<zignig> is Cyclone V 6lut of 4lut ?
<zignig> *or
<ZirconiumX> Eeeeeh
<ZirconiumX> It Depends(tm)
<ZirconiumX> It's configurable
<ZirconiumX> It's natively LUT4, but an ALM has LUT4s packed closely enough that going up to LUT6 is very cheap
<zignig> ok, still I think the Boneless will make a good backplane processor , I'm getting closer to a nmigen integration and a REPL.
<ZirconiumX> And you can sometimes get a LUT7 out of an ALM
<ZirconiumX> And yes, it will
indefini[m] has joined ##openfpga
jfng has joined ##openfpga
scream has joined ##openfpga
thehurley3[m] has joined ##openfpga
henriknj has joined ##openfpga
xobs has joined ##openfpga
swedishhat[m] has joined ##openfpga
ironsteel has joined ##openfpga
<ironsteel> hi guys, newbie question: is it possible to do HDMI input with the ECP5-5G, like electrically speaking, since the ECP5 does't have CML?
<tnt> ironsteel: pretty sure you can convert cml to lvds with some passives.
<q3k> fwiw the ulx3s has HDMI output directly from an ECP5
<q3k> with some ac coupling caps sprinkled in
<tnt> yeah, LVDS -> CML is just ac coupling (assuming the other end has a 100 ohm term).
<tnt> CML -> LVDS is ac coupling + biasing the LVDS at the right spot.
<ironsteel> tnt yup CML->LVDS is the tricky part for me
<tnt> just ac couple, use the internal 100 ohm of the ecp5 and then bias one of the line ~ 1.2V (using a high impedance > 10k resistor divider).
<ironsteel> thanks allot will try that, so on the FPGA side, going with DDR blocks instead of SERDES will suffice for testing lower bitrates/resotutions?
<tnt> yeah, most likely.
jemk has joined ##openfpga
carl0s has joined ##openfpga
Maya-sama has joined ##openfpga
Maya-sama has quit [Ping timeout: 276 seconds]
<whitequark> ZirconiumX: neither, it's just not defined *yet*
<whitequark> because i don't know what value to put there
<ZirconiumX> Maybe 0xF?
<whitequark> i don't see why
<ZirconiumX> Hmm.
ironsteel has quit [Quit: Ex-Chat]
emeb has joined ##openfpga
OmniMancer has quit [Read error: Connection reset by peer]
Bike has joined ##openfpga
unkraut has quit [Remote host closed the connection]
<GenTooMan> there wouldn't happen to be any nmigen examples (as opposed to migen examples) around? m-labs references (things) that are migen. Would it make more sense to use migen?
<whitequark> there are examples in the nmigen repository
Marex has quit [Ping timeout: 268 seconds]
Marex has joined ##openfpga
unkraut has joined ##openfpga
Marex has quit [Ping timeout: 246 seconds]
Marex has joined ##openfpga
Marex has quit [Ping timeout: 264 seconds]
Marex has joined ##openfpga
<GenTooMan> ok ... I guess I was wishing for more than what's there. :D Thanks
Marex has quit [Remote host closed the connection]
Marex has joined ##openfpga
rohitksingh has joined ##openfpga
<GenTooMan> Well I sort of got it to work, it appears nmigen uses yosys for simulation.
<ZirconiumX> It doesn't, it has its own simulator
<ZirconiumX> Called pysim
<GenTooMan> so why is it ... hmm interesting I wonder why it's doing this.. thanks for the heads up
<ZirconiumX> GenTooMan: Because it uses Yosys to process RTL
<GenTooMan> As I stated thanks for the heads up, as I was doing a simulation and not RTL synethesis I didn't need to convert it to verilog which would make the check for the yosys version.
<ZirconiumX> Just update Yosys if it's complaining
rohitksingh has quit [Ping timeout: 276 seconds]
rohitksingh has joined ##openfpga
swedishhat[m] has quit [*.net *.split]
scream has quit [*.net *.split]
scream has joined ##openfpga
swedishhat[m] has joined ##openfpga
<GenTooMan> I was avoiding it because I was trying to avoid distribution differences but with Yosys it's going to need it regardless. Looks like I have to install nexppnr too. However my design test isn't sunk because I can at least simulator without invoking the verilog conversion.
<ZirconiumX> You don't need nextpnr
<ZirconiumX> <--- Boneless imm3 decoder, though there's a DC state for AL immediate 3
<ZirconiumX> It's pushing fan-out a little, but the only gate not fully utilised is the inverters
rohitksingh has quit [Ping timeout: 276 seconds]
Asu has quit [Ping timeout: 245 seconds]
mumptai has joined ##openfpga
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 250 seconds]
Jybz has quit [Ping timeout: 252 seconds]
indy has quit [Ping timeout: 244 seconds]
<ZirconiumX> zignig: do you consider hooking up Boneless to some 65C22 VIAs to be cheating?
<whitequark> VIA?
<tnt> Versatile Interface Adapter
<ZirconiumX> They're still manufactured
<ZirconiumX> Useful for decoupling buses
<ZirconiumX> This is something else to consider; it's basically a UART
<ZirconiumX> Seems like there are better alternatives for the ACIA
<cr1901_modern> Modern ACIAs have bugs which make them effectively worthless
<cr1901_modern> until WDC decides to spin out a new revision
<ZirconiumX> Oh excellent
<ZirconiumX> Are the VIAs okay though, cr1901_modern?
<cr1901_modern> VIAs and PIAs are fine
<cr1901_modern> I have a few of them around for that 6502 SBC I say I'm going to do eventually
<cr1901_modern> yup, any year now
<cr1901_modern> Anyways WDC's VP contacted me directly regarding ACIAs- interrupts are broken, thus you'll either want to take a wait state hit with 16550 or make your own FPGA UART
<ZirconiumX> 16550s seem difficult to obtain
<cr1901_modern> 8250, 16450- basically the PC UART. Or make your own :P
<ZirconiumX> There's an argument to be made that broken interrupts are not a major problem on an architecture which currently does not support interrupts :P
<whitequark> lol
<ZirconiumX> There's the 16C750 which seems to be the upgrade path for the 16550
<cr1901_modern> If you really want to use the ACIA, here's the workaround
<ZirconiumX> It's more that the ACIA is obtainable :P
<cr1901_modern> oh right, the bug's worse than I remembered
carl0s has quit [Remote host closed the connection]
<cr1901_modern> the xmit bit is stuck on, so polling doesn't work either. You have to do a delay loop.
<ZirconiumX> Have they really not fixed this for six years?
<cr1901_modern> I don't know how WDC makes their money, and I
<cr1901_modern> m not sure I want to know. But yea, it seems they have no plans to spin a new one at this time
<cr1901_modern> I like this idea too
<ZirconiumX> I mean, there's exactly one company still making 6502 chips, and I guess when you've cornered the market the market doesn't need to be all that big
<ZirconiumX> You've really not got much choice in regards to DIP UARTs
<cr1901_modern> s/UARTs//
<cr1901_modern> Even for the SBC design I've given up doing a strictly DIP design
<ZirconiumX> I'm building a CPU out of 74xx chips: it's *feasible*, if not pretty to build it out of DIPs
mumptai has quit [Quit: Verlassend]
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 258 seconds]