<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
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?
<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
<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>
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
<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