00:15 <whitequark[m]> Degi: some configuration of openocd is necessary

00:18 <lkcl> Degi: we just set up a page which documents this, i have a FT232 here and wired it up to C4M-JTAG

00:18 <lkcl> slightly different but we researched the source code of openocd directly

00:19 <lkcl> there are "default" patterns (RX->TDI etc. etc. something like that) which if you obey *exactly* that configuration you do not have to change anything in openocd.cfg

00:20 <lkcl> search this page for the words "FT232R GPIO bit number" https://libre-soc.org/HDL_workflow/ECP5_FPGA/

00:21 <lkcl> if you choose to match EXACTLY those GPIO allocations on the FT232, you can then follow this diagram:

00:21 <lkcl> https://libre-soc.org/HDL_workflow/ft232.png

00:22 <lkcl> disconnecting the 3.3v-5.0V jumper entirely is CRITICALLY IMPORTANT

00:22 <lkcl> do not under ANY CIRCUMSTANCES try to have the power from the FPGA supplied *to* the FT232 at the same time as connecting the jumper which also supplies power from an on-board regulator

00:23 <lkcl> you absolutely must let the *FPGA* provide the VREF (Voltage Ref) *to* the FT232 so that the FT232 knows what the CMOS levels are

00:24 <lkcl> do not be tempted - at all - to think "oh the FPGA supplies 3.3v, the FT232 on-board regulator supplies 3.3v, therefore what's the big deal?"

00:25 <lkcl> the Big Deal is: one will be 3.31v (fluctuating), the other will be 3.20v (fluctuating) and you get a current fight between the two

00:25 <lkcl> one or both will lose that fight, and the Magic Smoke Genie will leave either (or both) devices

00:29 <lkcl> btw if you need to do something that's so low-level you don't even have a "target" (no pre-defined CPU as specified in openocd's configs), you can use something like this:

00:29 <lkcl> https://git.libre-soc.org/?p=libresoc-litex.git;a=blob;f=openocd_ft232.cfg;hb=HEAD

00:30 <lkcl> that's setting the interface to ft232, then the baud rate to 5khz (because i have 12 in dangling wires with no GND ribbon cable in between each signal)

00:31 <lkcl> then i have C4M JTAG set up with an ir width of 4, etc. etc.

00:31 <lkcl> it's a pretty basic bare-bones config.

01:01 <_whitenotifier-3> [YoWASP/yosys] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JO69h

01:01 <_whitenotifier-3> [YoWASP/yosys] whitequark b2f4bd1 - Update dependencies.

09:04 <Degi> lkcl: Neat, so I can just use a FT232H chip with that? I don't intend to use an adapter but the chip itself on a custom PCB, so the chip doesn't need to be specially configured to do JTAG but rather OpenOCD will do that for me? (For example on the ECP5 EVN board the FT2232 chip is connected to an EEPROM, I wondered what that is for)

09:10 <Degi> Oh, is that an FT232R? That can do JTAG?

09:12 <Degi> Yes, that looks good... So OpenOCD directly drives the GPIO and doesnt need any extra configuration...

10:55 <hell__> not sure if R variants can do JTAG (they do not support USB 2.0, which may be a bottleneck)

10:57 <agg> the ft232h is the usual choice i believe, then openocd doesn't need to wiggle gpio directly, the chip understands jtag (and spi and uart) natively

10:58 <lkcl> Degi: they do UART and they can be put into direct bit-banging mode (general purpose)

10:58 <agg> or 2232h, then you can have a usb-uart and usb-jtag at the same time

10:58 <lkcl> agg: neat!

10:58 <agg> (or usb-fifo and usb-jtag, which can be nice if you want a higher bandwidth pipe out of an fpga)

10:59 <lkcl> agg: i got a DTD Tech FT232R off of amazon, it was dirt-cheap, arrived in like a day :)

11:00 <Degi> Hm yes, then maybe the 2232h is the best choice. So it doesn't need any configuration apart from OpenOCD for the MPSSE?

11:02 <lkcl> https://github.com/openrisc/openOCD/blob/master/src/jtag/drivers/ft2232.c

11:02 <agg> table 4.11 (in section 4.13.1) of the datasheet is "do i need an eeprom?"

11:02 <agg> http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT2232H.pdf

11:03 <agg> for mpsse, looks like no, though an eeprom would let you customise the VID/PID and product strings

11:03 <agg> for the sake of a small cheap eeprom i'd probably fit it anyway

11:03 <agg> assuming that's what you mean by "any configuration" - the chip doesn't have any non-volatile memory built-in, so you often connect the eeprom to allow permanent configuration

11:03 <agg> (mpsse is what you need for jtag)

11:04 <hell__> the H variants can also be used as a SPI programmer with flashrom :-)

11:05 <Degi> Oh neat, so when I connect some pins to the SPI flash it can program it too?

11:05 <agg> yea, the 2232 has two interfaces, and each can be jtag or spi or uart or parallel FIFO to an fpga

11:05 <agg> if you don't include an eeprom they both default to uart and can be reconfigured to spi or jtag at runtime

11:06 <agg> eeprom also lets you store a serial number usb string which is handy for programming the right board if you ever have two ftdi chips plugged in at once, heh

11:06 <agg> what fpga are you using? some like ecp5 can pass-through spi flash to jtag, so you only need jtag connected

11:07 <Degi> Yes I want to use the ECP5 but AFAIK OpenOCD doesn't support that (yet)

11:07 <agg> huh, i would have thought it did

11:07 <agg> i don't use openocd so not sure

11:07 <Degi> At least somebody told me it didn't

11:07 <agg> openocd did just get a new release after like 3 years, for the longest time you had to build from source to get anything at all recent

11:07 <Degi> oh

11:07 <agg> anyway doesn't matter, if you're using ecp5 you can forego openocd and save yourself a load of pain

11:08 <agg> with ftdi, you can use https://github.com/gregdavill/ecpprog

11:08 <agg> which handles both loading bitstreams directly, and writing them to spi flash through the ecp5

11:08 <Degi> Oh that is very practical

11:08 <agg> or if you don't especially like ftdi (like me) i wrote https://github.com/adamgreig/ecpdap which can use any cmsis-dap debug probe to do the same thing (direct load or spi flash)

11:09 <agg> but if you just want a chip to solder to your pcb without much fuss, probably the ft2232h is an easier choice

11:10 <agg> sorry for dumping a ton of text, i remember it being a bit overwhelming when i was first looking into "how so how do i load bitstreams..."

11:10 <Degi> Yes I was too, maybe this should be documented somewhere well

11:10 <Degi> Thanks though!

11:10 <agg> i definitely recommend ecpprog instead of openocd for a plain ft232h->ecp5->spi flash setup, though, much simpler and easier

11:11 <Degi> So ecpdap can program the FPGA itself and program the flash separately? That sounds fine, maybe I'll just get a CMSIS-DAP probe, at least thats much cheaper than putting a FT2232H on every PCB

11:13 <agg> that's my strategy, i use the ARM 10-pin 0.05" debug connector that's common for SWD/JTAG, and then all my probes plug right in

11:13 <Degi> Nvm the FT2232H isnt available anywhere anyways

11:14 <agg> if you're making a development board it's sometimes nice to have the programming built-in, and sometimes you need a usb-uart or usb-fifo built in too, so it ends up being convenient to use the ftdi chip

11:14 <agg> lol of course

11:14 <Degi> Eh, I'll just use external UART, I guess worst case you can attach one to PMOD

11:14 <agg> wow yea looks like they're sold out across the board

11:15 <hell__> I'd try looking for `FT2232HL`

11:15 <Degi> Nope

11:16 <hell__> I have two FT2232HL modules from CJMCU: https://i.imgur.com/OIQE8om.jpg

19:06 <FL4SHK> so I've figured out what my DSL is going to generate: extended VHDL

19:07 <FL4SHK> well, extended only on my end

19:32 <FL4SHK> the code you write will generate the extended VHDL AST rather than just a VHDL AST

19:32 <FL4SHK> and I'll have to lower the DSL's AST into a VHDL One

19:41 <FL4SHK> ideas I've got are just convenience types

19:41 <FL4SHK> composite types

19:42 <FL4SHK> and, with this project, I'll be able to have VHDL variables!

19:44 <hell__> random idea: why not call this extended VHDL language EHDL?

19:44 <FL4SHK> that is a cool idea

19:44 <FL4SHK> but I've already named it

19:44 <FL4SHK> pyhdlgen

19:44 <hell__> ah

19:44 <FL4SHK> not too late to name it given that I have no users

19:44 <FL4SHK> rename

19:57 <FL4SHK> The reason I called it "pyhdlgen" instead of "pyvhdlgen" is in case I decide to have a way to generate SV or something

19:57 <FL4SHK> I'm starting with VHDL 2008

19:57 <hell__> hm