cr1901_modern has quit [Ping timeout: 250 seconds]
dj_pi has quit [Ping timeout: 248 seconds]
zachjs has quit [Remote host closed the connection]
zachjs has joined ##openfpga
unixb0y has joined ##openfpga
flea86 has joined ##openfpga
unixb0y_ has quit [Ping timeout: 245 seconds]
gsi__ has joined ##openfpga
gsi_ has quit [Ping timeout: 248 seconds]
lutsabound has quit [Quit: Connection closed for inactivity]
dj_pi has joined ##openfpga
dj_pi has quit [Ping timeout: 245 seconds]
zachjs has quit [Remote host closed the connection]
zachjs has joined ##openfpga
gnufan_home has quit [Quit: Leaving.]
zachjs has quit [Remote host closed the connection]
zachjs has joined ##openfpga
zachjs has quit [Ping timeout: 255 seconds]
emeb has left ##openfpga [##openfpga]
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
zachjs has joined ##openfpga
gnufan_home has joined ##openfpga
indy has quit [Remote host closed the connection]
rohitksingh_work has joined ##openfpga
jevinski_ has joined ##openfpga
jevinskie has quit [Ping timeout: 248 seconds]
jevinskie has joined ##openfpga
jevinski_ has quit [Ping timeout: 252 seconds]
lexano has quit [Ping timeout: 245 seconds]
lexano has joined ##openfpga
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
OmniMancer has joined ##openfpga
emeb_mac has quit [Ping timeout: 244 seconds]
craigjb has quit [Ping timeout: 250 seconds]
craigjb has joined ##openfpga
zachjs has quit [Remote host closed the connection]
zachjs has joined ##openfpga
zachjs has quit [Remote host closed the connection]
GuzTech has joined ##openfpga
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
<GuzTech>
Hmm, I'm trying to build the linux-on-litex-vexriscv repository for the Arty board, but I get an assertion error "unsupported variant linux".
ZombieChicken has quit [Remote host closed the connection]
<daveshah>
GuzTech: Your LiteX probably isn't up to date
<GuzTech>
I just updated it a few minutes ago
<daveshah>
Are you sure you don't have an old LiteX installed somewhere or something? I know the linux vexriscv variant was only added recently
<GuzTech>
Ok, so I updated now again and now it actually starts building...
<GuzTech>
Now I get an error compiling tapcfg...
<GuzTech>
But hey, it's not an error about an old vexriscv version :)
<GuzTech>
At uni, we use a custom SoC with microblazes, very specific old versions of GCCs (yes, plural) with custom patches, our own real-time OS with it's own GCC, a custom NoC, etc.
<daveshah>
Might need to litex_setup.py update
<GuzTech>
I want to port this old crap to use RISC-V cores.
<GuzTech>
So I want to see how well Linux runs on the vexriscv.
<daveshah>
It runs pretty well now that the MMU is sorted
<daveshah>
Boots in about 6 seconds or so
zachjs has joined ##openfpga
<daveshah>
No kernel patches at all using the SBI console
<GuzTech>
That's way faster than the microblaze we use.
<GuzTech>
Just booting from the compactflash card on the Virtex 6 board takes more than 30 seconds.
<GuzTech>
We use netcat so send the binary to the linux core, which then signals the other cores to boot from a certain location in memory.
<GuzTech>
So it's nothing special.
<daveshah>
Ah, I wasn't including download time in that 6 seconds
<daveshah>
Probably more like 10-12 seconds including it
<GuzTech>
That's still 3x faster.
<daveshah>
LiteX has a TFTP bootloader which is quite nice
<GuzTech>
I'll first get my hands dirty with LiteX, and then I'll look into the different ways we can load stuff onto the board.
<GuzTech>
Ok so it's synthesizing for the Arty, which I'll test in a minute.
<GuzTech>
Simulation doesn't compile however.
<GuzTech>
tapcfg/src/lib/tapcfg_unix_linux.h:64:2: error: ‘strncpy’ output may be truncated copying 15 bytes from a string of length 15 [-Werror=stringop-truncation]
<GuzTech>
_florent__: Yes, I think that's the same issue.
<GuzTech>
Should tapcfg not update when I run "litex_setup.py update"?
<_florent__>
GuzTech: it should, let me check if the submodule is updated
<GuzTech>
It doesn't update for me when I run it.
<_florent__>
can you try: git submodule update --recursive
<GuzTech>
I see you've split up the build dirs for the arty and the versa boards, but in arty.py, the "build" dir is used instead of "build_arty" for the laod and flash arguments.
<GuzTech>
Ok, so recursively updating the submodules updates tapcfg and simulation now works \o/. I do get an error that the server does not allow request for unadvertised object when fetching from the m-labs/VexRiscv-verilog repository.
rohitksingh has joined ##openfpga
<GuzTech>
I created a pull request for that.
<GuzTech>
I have one (hopefully) final problem: I cannot flash the binaries on the arty.
<_florent__>
thanks, merged
<GuzTech>
Loading works, but of course it cannot boot Linux since it's not in flash.
<GuzTech>
But when I want to flash it gives an error: Unknown flash device (ID 0x00ffffff)
<futarisIRCcloud>
GuzTech: You need to rebuild openocd.
<daveshah>
Yes, upstream kernel, although afaik 32-bit RISC-V Linux glibc still isn't upstream
<daveshah>
Because of some 2038 issue or something
<daveshah>
Buildroot fetches the correct version so it's not a big issue though
<ZombieChicken>
2038 is when 32-bit Unix time rolls over
<daveshah>
One of the reasons why all the distros are only looking at 64-bit RISC-V for now
<daveshah>
Indeed
<GuzTech>
I'm going to build everything from scratch (buildroot & kernel), so that I can see it with my own eyes.
<daveshah>
I understand they are trying to ensure the APIs 32bit RISC-V use avoid that unlike earlier 32bit arches
<GuzTech>
You don't want to know how much effort I had to put in to get our old crappy real-time system working on newer hardware.
<GuzTech>
We have students that use it for a course, but the PCs were like 11 years old and they broke down.
<ZombieChicken>
I thought rt systems were a 'build once, touch never' sort of thing
<ZombieChicken>
well, insofar as anything computer related can be that way
<GuzTech>
ZombieChicken: it's a system we generate to run on Virtex 6 boards, which is used for a real-time systems course.
<GuzTech>
It consists of microblaze cores and a custom NoC and real-time OS.
<GuzTech>
All of it hangs together with Makefiles upon makefiles upon makefiles upon old versions of software that only run with specific patches on specific versions of Ubuntu.
<GuzTech>
It's crap, and a hassle to maintain.
<GuzTech>
So I want to switch everything over to LiteX and RISCV.
<GuzTech>
Running Linux on a core is step 1.
<ZombieChicken>
less than 400 pages of reference manual. That's kinda nice
rohitksingh has quit [Ping timeout: 245 seconds]
ondrej3 has quit [Ping timeout: 245 seconds]
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ondrej3 has joined ##openfpga
emeb_mac has quit [Ping timeout: 250 seconds]
Asu has joined ##openfpga
Dolu has joined ##openfpga
Asu` has joined ##openfpga
Asu_ has joined ##openfpga
Asu has quit [Ping timeout: 252 seconds]
Asu` has quit [Ping timeout: 248 seconds]
cr1901_modern has joined ##openfpga
cr1901_modern1 has quit [Ping timeout: 245 seconds]
Asu_ has quit [Quit: Konversation terminated!]
zachjs has joined ##openfpga
gnufan_home has quit [Ping timeout: 250 seconds]
zachjs has quit [Ping timeout: 268 seconds]
gnufan_home has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
zachjs has joined ##openfpga
lexano has quit [Ping timeout: 246 seconds]
lexano has joined ##openfpga
carl0s has joined ##openfpga
zachjs has quit [Ping timeout: 248 seconds]
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
nickjohnson has quit [Read error: Connection reset by peer]
nickjohnson has joined ##openfpga
Asu has joined ##openfpga
rohitksingh has joined ##openfpga
jevinskie has joined ##openfpga
rohitksingh has quit [Ping timeout: 245 seconds]
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 248 seconds]
m4ssi has joined ##openfpga
emeb has joined ##openfpga
zachjs has joined ##openfpga
GuzTech has quit [Remote host closed the connection]
dj_pi has joined ##openfpga
zachjs has quit [Remote host closed the connection]
zachjs has joined ##openfpga
zachjs has quit [Ping timeout: 250 seconds]
flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
rohitksingh has joined ##openfpga
zachjs has joined ##openfpga
OmniMancer has quit [Quit: Leaving.]
zachjs has quit [Remote host closed the connection]
genii has joined ##openfpga
m4ssi has quit [Remote host closed the connection]
dj_pi has quit [Ping timeout: 245 seconds]
zachjs has joined ##openfpga
dj_pi has joined ##openfpga
zachjs has quit [Ping timeout: 246 seconds]
Asu has quit [Ping timeout: 245 seconds]
<SolraBizna>
is there some toy tool that accepts simple Verilog and attempts to produce a simple circuit using as few real discrete-logic parts as possible?
rohitksingh has quit [Ping timeout: 248 seconds]
Asu has joined ##openfpga
<whitequark>
that's kind of really hard
<SolraBizna>
then I guess I'd just settle for a catalog of real discrete-logic parts
<SolraBizna>
I had one years ago but lost it
rohitksingh has joined ##openfpga
<SolraBizna>
I'd think it would be easier than synthesizing Verilog in Minecraft, except that unlike that project it would have to actually do a good job
<SolraBizna>
it doesn't matter anyway, it took Richard_Simmons even less time than usual to convince me to use a GreenPAK instead of "just a few ICs"
<SolraBizna>
hey, that's the exact one I lost a few years ago
<SolraBizna>
thanks!
<hackerfoo>
Long ago you could get free hard copies, I don't know if you still can.
<Richard_Simmons>
I think the GreenPak4 chips are still available anyways, trying to figure out what it takes to program them
<hackerfoo>
SolraBizna: If you happen to be in the SF Bay area, you can have several tubes of discrete logic DIPs for free.
<azonenberg_work>
Richard_Simmons: you need the fofficial greenpak devkit
<azonenberg_work>
officialI*
zachjs has joined ##openfpga
<azonenberg_work>
The programming protocol is not documented, i have access to it privately and didnt even attempt to implement it
<SolraBizna>
I'll allow this deviation from my principles on the grounds that this is already a second-order deviation from the true project...
<azonenberg_work>
tl;dr the protocol is basically a factory test protocol, you put HV on Vpp and then you get all kinds of analog test points to internal IP etc brought out to the GPIOs
<azonenberg_work>
And a SPI-esque flash load protocol
<azonenberg_work>
its totally not something practical to do in circuic
<azonenberg_work>
circuit*
<SolraBizna>
hackerfoo: I don't, but I appreciate the offer
<azonenberg_work>
whitequark RE'd the usb protocol for their devkit so you can load bitstreams using open tools
<Richard_Simmons>
SolraBizna, don't we know someone in the area?
<SolraBizna>
we know a few, but it would be cheaper to order from a proper outlet than to ship as mortals (probably)
rohitksingh has quit [Ping timeout: 246 seconds]
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<SolraBizna>
the circuit I am / would be building has a grand total of five gates, and the "oh boy we have programmable logic" bonus feature edition wouldn't be much more complex
<Richard_Simmons>
the GreenPak devboards + sockets aren't cheap together... Justifiable if there's a lot of things to use them for though
rohitksingh has joined ##openfpga
<Richard_Simmons>
not cheap by my standards, anyways.
<SolraBizna>
AFAIK, this would be the only thing we would use them for
Dolu has quit [Ping timeout: 248 seconds]
<tnt>
SolraBizna: I had some project where I considered a greenpak ... but the cost of buying the dev kit for a couple of devices was just too much.
<tnt>
SolraBizna: I ended up using a ice40 lp384
<SolraBizna>
I'd normally go with an FPGA of some sort as well, but it's silly to replace two ICs with an FPGA, and that's where I'm at now
edmund has joined ##openfpga
<edmund>
-guztech how many Virtex6 board do you have in your school?
mumptai has joined ##openfpga
<tnt>
SolraBizna: yeah, 2 ICs is borderline ... depends on the IC. My other option was 3 discrete logic chips and that was (1) large on the PCB (2) more expensive ... :p I guess when you make 1000s the discrete logics can be super cheap but in single qty I actually do find they pretty expensive for what they offer.
<SolraBizna>
I managed to wrangle the entire bus logic into a 7400 and a 7403, which is just a bit cheaper than an LP384
<tnt>
SolraBizna: what's your project btw ?
<SolraBizna>
Richard_Simmons and I were working on a rugged, flexible computer with an FPGA-based CPU
<SolraBizna>
but I got scared by how many passives were on the board, and we decided that having ~80 tiny components on our first-ever PCB was asking for trouble :D
<SolraBizna>
so now I'm doing the bare minimum work to turn a W65C134S and an MRAM into something that's technically useful
<SolraBizna>
(flexible in the sense of "can be used for many purposes", not "can be physically flexed")
<Richard_Simmons>
speaking of rugged, were we doing anything about ESD?
<SolraBizna>
I kept forgetting to
<SolraBizna>
well, the 7432 (which is what I meant to type instead of 7403) basically doesn't exist anymore, so back to the whiteboard or forward to a GreenPAK
<tnt>
huh ? I see plenty of them.
<SolraBizna>
... you're right, I just suck at searching
<daveshah>
Strictly speaking I imagine the 7432 is hard to find these days (but plenty of 74HC/LS/etc32 around)
<daveshah>
I dare say, pence per gate doesn't compare well against an FPGA...
<SolraBizna>
using an FPGA would mean adding a 1.2V supply and a configuration memory
<tnt>
OTP
<daveshah>
or use something like an xo2
<SolraBizna>
using OTP would mean getting equipment we don't have, and we're poor
<whitequark>
ice40 can be OTPd with nothing but SPI
<tnt>
getting equipement you don't have ?!?
<tnt>
daveshah: we're impatiently waiting for nextpnr support for it :p
<SolraBizna>
yeah, that was a misfire
<SolraBizna>
the 1.2V supply is the bigger deal here
<SolraBizna>
for this application we could use a simple linear regulator, but gross!
<TD-Linux>
2 74 series chips? yeah just use chips
<sorear>
throw a resistive divider on 3v3, what could go wrong
<SolraBizna>
I even considered using a small PROM, but they were all too big and too slow
Dolu has joined ##openfpga
<SolraBizna>
the truth table has six inputs and four outputs, it's frustratingly simple
Dolu has quit [Ping timeout: 258 seconds]
dj_pi has quit [Ping timeout: 248 seconds]
kbeckmann has quit [Ping timeout: 252 seconds]
kbeckmann has joined ##openfpga
iximeow has quit [Ping timeout: 252 seconds]
iximeow has joined ##openfpga
Jybz has joined ##openfpga
dj_pi has joined ##openfpga
_whitelogger_ has joined ##openfpga
craigjb has quit [Ping timeout: 248 seconds]
zem has quit [Ping timeout: 248 seconds]
zem has joined ##openfpga
_whitelogger has quit [Ping timeout: 248 seconds]
carl0s has quit [Quit: Page closed]
Jybz has quit [Quit: Konversation terminated!]
zachjs has quit [Remote host closed the connection]
cr1901_modern1 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 246 seconds]
rohitksingh has quit [Ping timeout: 255 seconds]
zachjs has joined ##openfpga
Richard_Simmons has quit [Ping timeout: 250 seconds]
Bob_Dole has joined ##openfpga
dj_pi has quit [Ping timeout: 250 seconds]
Miyu has quit [Ping timeout: 250 seconds]
edmund has quit [Ping timeout: 246 seconds]
Dolu has joined ##openfpga
mumptai has quit [Quit: Verlassend]
cr1901_modern has joined ##openfpga
cr1901_modern1 has quit [Ping timeout: 250 seconds]
genii has quit [Remote host closed the connection]
Asu has quit [Remote host closed the connection]
Dolu has quit [Quit: Leaving]
Dolu1990 has joined ##openfpga
zachjs has quit [Remote host closed the connection]
cr1901_modern has quit [Ping timeout: 248 seconds]
<adamgreig>
i wired SPI1's two mosi and miso mappings together
<adamgreig>
so you can set pa6/7 to hi-z and pb4/5 to af0 to get one way, or pa6/7 to af0 and pb4/5 to hi-z to get the other way
<emeb>
Cool - unfortunately there's only one mapping on the TSSOP package.
<adamgreig>
yea, i guessed
<adamgreig>
my bmp firmware bitbangs the spi
<adamgreig>
but it's very slow
<adamgreig>
and wasn't very reliable at flash programming for some reason i never got to the bottom of, though worked great for fpga loading directly
<emeb>
the f042 is pretty quick
<adamgreig>
sure, the bitbanging was slow for various stupid reasons
<emeb>
seems faster than the FT2232 even
<adamgreig>
i am currently deep into the usb spec to try and write my own usb stack for the first time
<adamgreig>
seemed about time to learn how usb works
<tnt>
adamgreig: welcome to the club :p
<emeb>
You're way ahead of me. Just copypasta the ST examples for now.
<tnt>
adamgreig: doing that right now.
<adamgreig>
right, my previous one used a library to get cdc-acm serial
<adamgreig>
but this time i want a real control endpoint for setting direction/cs/etc and a bulk endpoint for streaming data each way
<adamgreig>
with actual delimited packets etc
s_frit has quit [Ping timeout: 255 seconds]
<adamgreig>
and the computer side software will have to use libusb instead of just writing to a serial port
<emeb>
sounds fun
<adamgreig>
so it's hugely more complicated than my previous one in every way, lol
<emeb>
Idle hands, etc.
<tnt>
adamgreig: you don't need an EP, you can use custom control request over EP0
<adamgreig>
yea the usual "fun"
<adamgreig>
you know it
<adamgreig>
tnt: i'm using control reqs over ep0 for stuff like cs, fpga reset, swapping direction, enabling target power
<adamgreig>
and then want to do bulk on ep1 for streaming the actual data
zachjs has joined ##openfpga
<emeb>
One thing I'd like to explore is a composite device so I can use the UART port on the F042 simultaneously.
zachjs has quit [Remote host closed the connection]
zachjs has joined ##openfpga
<tnt>
adamgreig: ok. I thought you were going to do control transfers over a custom ep (!=0).
<adamgreig>
control is limited to 64B/packet whereas bulk i can do much bigger packets
<adamgreig>
ah no i do intend to use ep0 for it
<tnt>
and althought it's technically possibly, I've never seen it done.
<adamgreig>
until i discover that's somehow super difficult in libusb or whatever
<adamgreig>
yea why would you
<adamgreig>
this has been almost enjoyable so far but gosh i prefer ethernet
<adamgreig>
emeb: anyway i enjoy that we both had the same problem, the same annoyance with using an ftdi chip, and ended up at almost exactly the same solution :P
<adamgreig>
reading your readme is like reading my mind a couple weeks ago
<emeb>
adamgreig: no kidding.
<whitequark>
tnt: i don't think any OS can do it
<whitequark>
possibly not even many HCIs?
<tnt>
whitequark: very possible, I never looked into it much. I just decided against supporting it in my stack as "no worth implementing" :p
<adamgreig>
tnt: what are you writing exactly?
<adamgreig>
i love how you can tell synopsys did both the ethernet and usb peripherals on the stm32
<tnt>
adamgreig: I wrote a USB core for the ice40. I proved it works with a quickly thrown together stack, but now I'm trying to come up with something decent (i.e. reusable for many applications)
<adamgreig>
evidently they were not being paid to copy-edit their documentation
<adamgreig>
nice
<emeb>
Synopsys IP documentation has always been... meh.
<adamgreig>
some real annoying register quirks
<adamgreig>
like all the EP registers having mostly "set to toggle" fields
<adamgreig>
so those fields are "write 0 to leave alone", but other fields on the same register are "write 0 to clear"
<emeb>
*eyeroll*
<emeb>
adamgreig: good luck building your board - looking forward to hearing how it goes - especially the fancy-pants USB stack you're planning.
<adamgreig>
thanks, enjoy your actually working tool!
<adamgreig>
i look forward to building a usb protocol analyser next, to work out why my stack is not working :p
<emeb>
hah!
<emeb>
Yeah - mine is proving to be pretty useful. I got the initial FPGA-only version working a few months ago. Just got the new one last week and added the Flash handling code over the weekend.
<emeb>
Has been handy for my little iCE40 / 6502 foolishness.
<adamgreig>
yea totally, i've been using the hacked up BMP for my ice40s for a while
<adamgreig>
and a python script a lot like your cdc_prog :p
<emeb>
Nice. I should probably polish my python chops a bit and try that approach.
<azonenberg_work>
If anybody is interested i have a usb protocol decoder in libscopehal
<azonenberg_work>
1.x full speed right now, high and low will be easy to add once i have time to test them
<azonenberg_work>
i'm working on bringing it up in glscopeclient using whitequark's rigol
<adamgreig>
how much bandwidth do you need to capture full speed?
<azonenberg_work>
12 Mbps so low tens of MHz?
<adamgreig>
hm
<adamgreig>
i have a siglent but it has ethernet scpi
<adamgreig>
i was mostly joking about making a protocol analyser but actually i'd love to try glscopeclient with my siglent and see what i can get out of it
<whitequark>
azonenberg_work: i think i have some LS devices btw
<azonenberg_work>
adamgreig: which siglent
<adamgreig>
1202X-E
<adamgreig>
though i think all the scopes speak broadly the same scpi
<adamgreig>
in any event i've dumped waveforms from it over ethernet before
<azonenberg_work>
Hop in #scopehal for development chatter... error_404 has a siglent that he is working on making a driver for
<tnt>
azonenberg_work: mm, IIRC the rigol protocol is very similar to the agilent.
<Bob_Dole>
speaking of low tens of mhz, those cheap chinese DSO's with just a MCU and ADC now have a 30mhz model. I know those type are usually bad, but I'm curious how bad...
<azonenberg_work>
tl;dr at least some siglents are lecroy clones because siglent oem'd for lecroy
<azonenberg_work>
and i have a very solid lecroy driver
<azonenberg_work>
so you can subclass it and fix the siglent specific stuff and get it working relatively easily
<azonenberg_work>
most of the work is working around firmware bugs in the siglent implementation
<azonenberg_work>
Which is what he's focusing on now
<emeb>
I've got an 1104X-E - pretty nice scope for the $$