<tpb>
Title: GitHub - davidthings/tinyfpga_bx_usbserial: USB Serial on the TinyFPGA BX (at github.com)
<tnt>
promach: It's usb full-speed.
<promach>
so, it is USB 2.0
<promach>
tnt
<tnt>
It's USB 2.0 compliant (well ... maybe, didn't check if they passed the compliance tests), but it doesn't use the 'High-Speed' mode that was introduced in USB 2.0.
<tnt>
LS = Low Speed = 1.5Mbps FS = Full Speed = 12 MBps HS = High Speed = 480 MBps.
<tnt>
you can do LS and FS using normal IO pins/CMOS drivers.
<tnt>
for HS you need a dedicated PHY chip.
<promach>
ok
<corecode>
hi
<corecode>
i wonder whether a HS USB SIE done using a softcore would be smaller and easier to maintain than a monolithic design
<promach>
SIE ?
<corecode>
serial interface engine
<MoeIcenowy>
I heard that Lattice claims USB on Lattice FPGAs w/o ext PHY is not possible
<corecode>
because they didn't certify it for usb
<tnt>
corecode: what do you mean monolithic ?
<corecode>
non-microprogrammed
<tnt>
Oh. Well it's not HS (only FS), but ATM I'm doing a USB core that implements the 'usb stack' in a CPU. Much like you would find an common microcontroller. Packet level stuff is done in hardcoded logic. Transaction stuff is done in a microprogrammed state machine, and then the higher "transfer" layer is left to the CPU to do.
<corecode>
the SIE
<corecode>
are you doing a HS SIE?
<corecode>
i don't know too much about HS frames
<tnt>
no, FS only. I don't want an external PHY.
<corecode>
okay
<corecode>
is there much to do even?
<MoeIcenowy>
I think USBASP is some USB LS implemented in software with 8-bit AVR...
<corecode>
i think you only have so many bit times to answer ack/nak
<tnt>
The transaction layer needs to be fast, you only have 6.5 bit time to respond in FS.
<tnt>
So when you get a IN or OUT token, you have to decide fast what to answer.
<corecode>
right, so that needs to be in a register already
<MoeIcenowy>
maybe implementing LS will be more loose?
<corecode>
LS will be the same, just slower
<corecode>
1/10
<MoeIcenowy>
USB is too strict!
<MoeIcenowy>
(escape
<corecode>
what
proteusguy has quit [Ping timeout: 246 seconds]
<tnt>
corecode: yeah, I have basically just enough time to fetch from RAM the endpoint status and start the reply. That's why the transaction layer is still done in 'logic' (ok, microprogrammed, but still not quite a generic CPU) and not by just the soft core.
<corecode>
ah you don't keep the EP in registers?
<tnt>
No, I keep buffer rings in a RAM.
<tnt>
And fetch/writeback when starting/finishing the transaction.
<corecode>
ok
<tnt>
I wanted to be able to handle many endpoints without too much overhead.
<corecode>
yea i understand
<tnt>
Although technically you can only have 16 endpoints :/
<corecode>
technically?
<corecode>
also, bidirectional
<corecode>
plus multiple buffers
<tnt>
The EP field is 4 bits
<corecode>
yes
<tnt>
Oh yeah, endp numbers can be re-used for IN/OUT.
<tpb>
Title: USB in a NutShell - Chapter 1 - Introduction (at www.beyondlogic.org)
<corecode>
i know usb
<promach2>
MoeIcenowy : no worry, with few weeks of practice, you could do 0201 with only soldering gun under few seconds
<corecode>
promach2: what are you working on?
<promach2>
corecode : huh ?
<MoeIcenowy>
promach2: I have no soldering gun
<MoeIcenowy>
only soldering iron
<emeb>
heh
<promach2>
same thing
<corecode>
promach2: what project are you working on?
<corecode>
you seem to be doing usb, network on chip, etc.
<MoeIcenowy>
oh I thought you meant heating gun
<promach2>
no, you do not need hot-air gun
<corecode>
hot air station is important
<corecode>
and cheap
<promach2>
soldering iron is way cheaper
<promach2>
and precise
<corecode>
good one not
<promach2>
corecode : going to start on usb once I am done with NoC
Thorn has joined #yosys
<corecode>
is this for work or a hobby?
<MoeIcenowy>
I'm thinking whether I will be able to solder iCE40UP5K-SG48I with soldering iron
<daveshah>
The exposed pad will be tricky, and can't be skipped because it's the only grounding
<MoeIcenowy>
daveshah: I reserved a through hole for it
<emeb>
that's what kevin hubbard does - great big hole in middle of the exposed pad
<emeb>
fill in w/ solder from the back
<emeb>
I just use paste + hot air to solder those QFNs
<corecode>
MoeIcenowy: no, use hot air
<MoeIcenowy>
I remember once I got a free unsoldered GD32F150G8U6 board from JLC
<MoeIcenowy>
and finally I disposed it
<corecode>
you don't need paste, but you need hot air
<MoeIcenowy>
as I found I'm not able to solder the exposed pad of GD32F150G8U6
<MoeIcenowy>
my table is too small to keep a hot air gun...
<corecode>
ok
<corecode>
i guess you can find some solder ninja just around the corner
<emeb>
corecode: so all your u4k work got accepted into mainline?
<corecode>
yes
<emeb>
\o/
* emeb
goes to pull & rebuild
<promach2>
u4k ?
<emeb>
older lattice ice40 ultra stuffs
<cr1901_modern>
Ahhh someone was gonna offer me hardware to do ultra RE, but I got too busy. Nice work
<cr1901_modern>
is ultralight still up for grabs?
<daveshah>
cr1901_modern: yeah ultralite still available
<daveshah>
happy to pay for hw too
<cr1901_modern>
hmmm tempting. (for the record, someone _else_ was gonna offer me h/w, but they're on social media break atm)
<cr1901_modern>
I've been trying to coordinate w/ Andres, but the times we are awake/active don't seem to coincide
<cr1901_modern>
corecode: You did just the 4k family of ultra?
<daveshah>
there is only the ultra 4k
<daveshah>
the other parts are pseudo-devices
<daveshah>
ditto there is only one ultralite
<cr1901_modern>
ahhh, well ultralite is about machxo2-1200 level of complexity
<daveshah>
yeah, although probably less fuzzer hacking needed as I think it is closer to the ice40up than the xo2 is to the ecp5
<cr1901_modern>
let me touch base w/ andres.
<cr1901_modern>
corecode: MachXO2 is probably going to reach a point of usability soon. Would be happy to help w/ ultralite if you want to do it (or start it myself when machxo2 reaches minimum viable product).
<emeb>
daveshah: is u4k also in yosys & nextpnr?
<daveshah>
yes
<emeb>
nice
emeb_mac has joined #yosys
emeb_mac has quit [Client Quit]
<MoeIcenowy>
is someone doing MXO2 RE?
<cr1901_modern>
MoeIcenowy: Me, technically but it's stalled due to chronic "I can't multitask"-itis
lutsabound has joined #yosys
rohitksingh has quit [Ping timeout: 244 seconds]
rohitksingh has joined #yosys
keesj has joined #yosys
<corecode>
if you're going to put in dozens of hours for reversing, $30 for an eval board is negligible
<MoeIcenowy>
I think I have seen some LCMXO2-4000HC-4MG132 board for CNY ￥169
<MoeIcenowy>
~$25.15
AlexDaniel has joined #yosys
citypw has quit [Ping timeout: 259 seconds]
rohitksingh has quit [Ping timeout: 246 seconds]
<emeb>
always fun when building yosys to get to the 95% point where ABC takes the other 95% of the time. :)
<shapr>
I can build yosys so fast on my new laptop... now if I only had some clue about verilog
<shapr>
even the most powerful hardware does not increase my skills all by itself
m4ssi has quit [Remote host closed the connection]
rohitksingh has joined #yosys
<emeb>
lots to learn
<emeb>
corecode: daveshah: trying to build a simple blinky for u4k. yosys seems to work but nextpnr gives Fatal error: file not found --u4k
<emeb>
when i do --help for nextpnr it lists --u4k as a device option though. what am I doing wrong?
<tnt>
arf, you need 'input wire' and not just 'wire' ....
<ylamarre>
... VHDL has a nice "feature for this kind of assignement where you can assign parts of a signal then give a "default value" to others....
* ylamarre
wonders if nMigen and/or MyHDL have this feature...
<tnt>
ylamarre: oh yeah right. tbh I mostly used that to assign 0 to the whole verctor :p x <= (others => '0'); :p
<ylamarre>
Yes, but you can also do weird slices that way too.
<ylamarre>
Most missed feature when I had to transfer to verilog.
<tnt>
Damnit, iverilog doesn't like my function either ... syntax error :/
<tnt>
'input wire' -> 'input'
gsi__ is now known as gsi_
<tnt>
Mmm, yosys doesn't seem to like the 'new style' of having the reset at the end of the process when using a 'case' and an async reset : https://pastebin.com/NWwTrNmz
<tpb>
Title: always @(posedge clk or posedge rst) begin case (d) - Pastebin.com (at pastebin.com)
<tnt>
ERROR: Multiple edge sensitive events found for this signal!
<emeb>
I remember Clifford advocating for the "reset at end" style. Interesting that yosys doesn't like it sometimes.
<ylamarre>
Looks like it's more about the always block then the reset location...
<ylamarre>
Coded this way it looks like you have two clocks.
<tnt>
daveshah: Ok, indeed, so it's not yosys specific. It's just that in verilog with async reset you don't have a choice you _must_ use the legacy style resets. Good to know.
<tnt>
TIL :)
<daveshah>
However, aiui, async reset blocks don't have the "not putting a signal in the reset block makes reset a clock enable instead of just ignoring reset" problem as with sync resets
<daveshah>
so the only problem is inconsistency, the actual advantage of the reset at end style isn't present
<tnt>
Yeah, I was going for consistency :) But I never do process that have mixed reset/non-reset signals anyway, so the 'end style' is really just a 'style' for me ... no actual benefit.