Cerpin has quit [Remote host closed the connection]
Cerpin has joined #yosys
Cerpin has quit [Remote host closed the connection]
emeb has quit [Quit: Leaving.]
rohitksingh has joined #yosys
PyroPeter has quit [Ping timeout: 258 seconds]
rohitksingh has quit [Remote host closed the connection]
PyroPeter has joined #yosys
citypw has joined #yosys
analognoise has joined #yosys
gsi__ has joined #yosys
gsi_ has quit [Ping timeout: 246 seconds]
analognoise has quit [Ping timeout: 250 seconds]
rohitksingh_work has joined #yosys
_whitelogger has joined #yosys
analognoise has joined #yosys
Thorn has joined #yosys
kraiskil has joined #yosys
m4ssi has joined #yosys
Thorn has quit [Ping timeout: 245 seconds]
kraiskil has quit [Ping timeout: 250 seconds]
emeb_mac has quit [Ping timeout: 255 seconds]
kraiskil has joined #yosys
kraiskil has quit [Ping timeout: 268 seconds]
Thorn has joined #yosys
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
kraiskil has joined #yosys
kraiskil has quit [Ping timeout: 250 seconds]
eightdot has quit [Ping timeout: 250 seconds]
kraiskil has joined #yosys
kraiskil has quit [Max SendQ exceeded]
kraiskil has joined #yosys
kraiskil has quit [Ping timeout: 250 seconds]
citypw has quit [Ping timeout: 244 seconds]
kraiskil has joined #yosys
cr1901_modern has quit [Ping timeout: 258 seconds]
analognoise has quit [Ping timeout: 250 seconds]
cr1901_modern has joined #yosys
togo has joined #yosys
rohitksingh_work has quit [Read error: Connection reset by peer]
kraiskil has quit [Ping timeout: 246 seconds]
kraiskil has joined #yosys
rohitksingh has joined #yosys
maikmerten has joined #yosys
rohitksingh has quit [Ping timeout: 250 seconds]
rohitksingh has joined #yosys
kraiskil has quit [Ping timeout: 268 seconds]
rohitksingh has quit [Ping timeout: 246 seconds]
kraiskil has joined #yosys
kraiskil has quit [Max SendQ exceeded]
kraiskil has joined #yosys
kraiskil has quit [Ping timeout: 264 seconds]
gsi__ is now known as gsi_
<mithro>
daveshah: I recommend enabling the WIP bot on the YosysHQ organization -> https://probot.github.io/apps/wip/ -- it just prevents accidentally merging pull requests which have WIP in the title....
<tpb>
Title: Work In Progress | Probot (at probot.github.io)
eightdot has joined #yosys
m4ssi has quit [Remote host closed the connection]
kraiskil has joined #yosys
emeb_mac has joined #yosys
cdleary has joined #yosys
kraiskil has quit [Ping timeout: 246 seconds]
kraiskil has joined #yosys
cdleary has quit [Ping timeout: 250 seconds]
rohitksingh has joined #yosys
rohitksingh has quit [Ping timeout: 244 seconds]
mjacob has quit [Ping timeout: 252 seconds]
rohitksingh has joined #yosys
dys has joined #yosys
rohitksingh has quit [Read error: Connection reset by peer]
kraiskil has quit [Ping timeout: 250 seconds]
maikmerten has quit [Remote host closed the connection]
emeb has joined #yosys
<janrinze>
ZipCPU: the 'old' code for SDcard worked 'out of the box' :-)
<ZipCPU>
janrinze ... was that your old code?
<janrinze>
ZipCPU: not particularly fast but plenty compatible.
<ZipCPU>
Software control, or HDL control?
<janrinze>
Oh, it's some bitbanging code in C that pretends to be a SPI port for the SDcard.
<janrinze>
Software control.
<janrinze>
Since that works well it should be possible to migrate that to HDL if i can find the time.
<ZipCPU>
Sure! But now, you don't need to find the time quite so fast
<janrinze>
ZipCPU: Now the flash bootloader works.. indeed. no need
<janrinze>
More time to check some nasty bug in my compiler :-)
<ZipCPU>
"nasty bug" ... sigh... I've never seen bugs quite so nasty as those in FPGA designs
<janrinze>
bumped into another one?
<ZipCPU>
Not today, no ... but thanks for asking ;)
<ZipCPU>
No, today's current task is to see if I can't verify erasing the flash faster if I put a CPU into the FPGA
<ZipCPU>
It was going to be using an accelerator, but programming the flash is just too slow so far
<ZipCPU>
... and the reason why its too slow is my own fault. The debugging bus I put into this project just ... isn't industrial strength (yet)
<janrinze>
How slow is 'slow'?
<ZipCPU>
I haven't timed it, so about all I can say is slower than my level of patience
<janrinze>
:-D
<ZipCPU>
Watching the same value transfer across the bus over, and over, and over ...
<ZipCPU>
I know it can be much faster
<janrinze>
Do you have it in GIThub or is it not public?
<tpb>
Title: GitHub - ZipCPU/arrowzip: A ZipCPU based demonstration of the MAX1000 FPGA board (at github.com)
<ZipCPU>
janrinze: If there's something particular you are looking for, let me know. Perhaps I could save you the search?
<janrinze>
dualflexpress.v is the one?
<janrinze>
Was looking into that.
<ZipCPU>
That's the Verilog version of the flash controller, yes
<ZipCPU>
The C++ half of it is found in sw/host/flashdrvr.cpp
<janrinze>
Then i got that right :-)
<ZipCPU>
dualflexpress isn't really the problem. That's not the slow part.
<ZipCPU>
The slow part is sending data over the serial port interface. Once to determine if it needs to be erased, once to verify the erase, once to check if a page needs to be programmed, once again to program the page ... it's a lot of work on a serial port
<janrinze>
Okay, what baud rate?
<ZipCPU>
1MBaud
<ZipCPU>
although the data's being sent in (cough) hex. So, only 4-bits of useful data per byte
<janrinze>
I see.. that's a tad over 60 KB /sec max
<janrinze>
Assuming the hex coding.
<ZipCPU>
It gets worse. It takes me roughly 11 characters to send 32-bits of data, counting the carriage return and newline
<janrinze>
so about 30% actual data.
<ZipCPU>
Yeah, about that
<ZipCPU>
And ... the data gets sent about 4 times at that 30% rate
<janrinze>
still it would only be 3 times faster if you could eliminate that at 1Mb/s
<ZipCPU>
While it's not optimum, it is low logic ...
<ZipCPU>
Yes, that would be faster, and yes I have a project to do that, it's .... not getting much attention these days. ;)
<janrinze>
Have you tried FTDI parallel to USB? that can do about 20 MB/s (assuming USB2)
<ZipCPU>
I've also got another routine that gets a much better compression rate, skipping newlines and carriage returns, using a codebook to repeat things, it just doesn't fit in these small devices
<ZipCPU>
No. I haven't tried any of the faster FTDI modes
<ZipCPU>
There's a fast serial mode that I'd love to try to--should get up to nearly 50Mbps IIRC
<ZipCPU>
(You mean 20Mb/s, right? or 20MB/s?)
<janrinze>
USB2 should be capable of 480Mb/s (bits)
<ZipCPU>
Ahm, no.
<ZipCPU>
I think your best rate is 12Mb/s over USB
<janrinze>
That's USB 1.1 right?
<janrinze>
USB 3 does 5Gb/s
<ZipCPU>
There is a 480Mb/s speed, but I think it requires USB3
<ZipCPU>
It's also out of reach of most FPGAs
<daveshah>
USB2 HS is 480Mb/s
<daveshah>
It's a bit of a pain for FPGAs because of clock recovery, and it's mixed single ended and diff signalling
<ZipCPU>
daveshah: I didn't think that was until USB 3 ... did I miss that?
<daveshah>
USB3 is 5Gbps
<ZipCPU>
Nvm then
<daveshah>
Many USB2 devices only support the 12Mbps mode
<ZipCPU>
You think the FTDI controller would handle 480Mbps? FT2232H?
<daveshah>
It's "high speed" devices that add 480Mbps support
<daveshah>
Yes, the H is for high speed :)
<ZipCPU>
Ok ...
<janrinze>
daveshah: using a FTDI chip for USB to parallel can relieve the bit speed at the FPGA side, right?
<daveshah>
I think it's only sync fifo mode that gets close to that
<daveshah>
janrinze: yes
<daveshah>
There's even a FTDI USB3 to parallel
<janrinze>
I never tried the FTDI parallel printer interface in my bottom drawer.. should be bi-directional, right?
<daveshah>
Yes
<daveshah>
I think a lot of the FTDI parallel printer chips are 12Mbps only though
<janrinze>
probably, they are quite cheap.
<janrinze>
Still, 12 times faster than the 1Mbps he has now :-D
<ZipCPU>
Let's see ... 1Mbps * 30% * 1/4 ~= 75 kbps, or 9kB/s
<ZipCPU>
I might get the biggest bang for my buck by switching from this hexadecimal encoding to something smarter
<emeb>
seems like it'd be good to just send the data once, queue it in a flash-page sized RAM in the FPGA and then let local logic do the compare/erase/program/verify without resending.
<ZipCPU>
emeb: That's actually the approach I'm pursuing now.
<emeb>
ZipCPU: validation! :)
<ZipCPU>
I'll feel better about it once it works ...
<emeb>
lots of opportunity for formal!
<ZipCPU>
Ok, I misunderstood you .... I'm using the CPU instead of the logic to do this
<ZipCPU>
Not nearly as many opportunities for formal as a result
<emeb>
ZipCPU: no, understood me - I didn't specify cpu or logic. I'd guess a fully dedicated logic implementation would be a lot more hassle than just throwing a CPU at it.
<ZipCPU>
Ok, I'll agree with that
<emeb>
Especially if you just happen to have a CPU laying around - as you do.
<ZipCPU>
:D
<emeb>
Had the opposite situation yesterday - was doing a PS/2 keyboard receiver. Had to choose between doing the scan-code to ASCII conversion in software or in verilog.
<janrinze>
ZipCPU: no USB device for the CPU yet, right?
<emeb>
Verilog turned out to be pretty easy and used less resources!
<ZipCPU>
janrinze: You mean like tinyfpga has been using?
<emeb>
(vs using up psedo ROM in the CPU address space)
<ZipCPU>
Got to run here .... suppertime
<emeb>
<insert Snoopy cartoon>
<janrinze>
ZipCPU: if there is no USB hw and you need to add it in Verilog, there are a few implementations but i found them quite complicated.
<emeb>
USB PHY is not a simple thing
<emeb>
you can tell it was designed by committee
<cr1901_modern>
daveshah: >and it's mixed single ended and diff signalling
<cr1901_modern>
IME, in a pure FPGA impl, you treat both signals as single-ended all the time, and if you see a SE1, then something really really bad happened :).
<daveshah>
I don't think that works for HS
<cr1901_modern>
well HS doesn't even have the proper voltages to interface to FPGA
<daveshah>
Maybe with a very short cable, not sure what the levels are
<cr1901_modern>
1.2V something
<cr1901_modern>
daveshah: Actually idk the voltage offhand either
<cr1901_modern>
But it isn't 3.3
<daveshah>
1.2V is fine for FPGAs
<cr1901_modern>
+/-400mV
<cr1901_modern>
sorry
<cr1901_modern>
Also while they are on my mind: Is it possible/feasible to break up the compilation of the nextpnr and icetime databases into smaller granularity units as a build option? This would enable me to recompile nextpnr/icetime more easily on ARM systems w/ < 4GB RAM
<cr1901_modern>
tnt gave a partial solution for icetime, but up5k icetime db still exceeds 2GB of RAM and brings my pinebook to its knees
<cr1901_modern>
nextpnr takes 4 hours to compile
<cr1901_modern>
(going to swap on a USB stick)
<daveshah>
icetime might be splittable further into functions
<daveshah>
Not so sure about nextpnr
<daveshah>
If it's creating the bbas that is slow then prebuilding is the solution
<cr1901_modern>
Then shouldn't there be daily blobs for that?
<daveshah>
The bbas are truly arch independent, the cc/bin only depend on endianness
<daveshah>
Yes, but no one has got round to setting up the infra for that
<cr1901_modern>
daveshah: Don't remember which step is the one that takes up all that time
<cr1901_modern>
I _think_ it was the bba generation
<daveshah>
You can use this repo to build a bin chipdb that is then passed to nextpnr
<daveshah>
Instead of building the bba during the main build process
<cr1901_modern>
The chipdbs are large, correct?
<cr1901_modern>
i.e. hundreds of megs
<cr1901_modern>
large == "github would get pissed if they were hosted as blobs in a repo"
<daveshah>
Yes
<daveshah>
They compress quite nicely though
<daveshah>
IIRC about 10-20MB xz for all ice40 chipdbs
<cr1901_modern>
If that's true, then I know a workaround to host the blobs in nextpnr-chipdb every time a travis build occurs
<cr1901_modern>
so you don't need to add a tag to each commit
<cr1901_modern>
you can create a separate branch with just the tarballs/zip files that's automatically updated each commit :P
<daveshah>
If you want to be fancy, only commits touching certain files (bbasm, the Python script that creates the bbas, and constids.inc) need a new db
<emeb>
cr1901_modern: hmm... I just built icestorm/yosys/nextpnr on a 2GB EEE laptop. It took a few hours, but it all fit.
<emeb>
OTOH It has an SSD and 2GB swap
<emeb>
how do ppl get the toolchain installed on an RPi Zero? Are there precompiled versions?
mjacob has joined #yosys
futarisIRCcloud has joined #yosys
<cr1901_modern>
emeb: Sure it still can be done. I just don't want it to go to swap
<cr1901_modern>
even on -j1 it goes to swap. Contrast to last year, the last time I built arachne-pnr and icetime, I could compile on 1GB RAM and a bit of swap
<cr1901_modern>
(without swap making the machine unusable)