Sprite_tm has quit [Remote host closed the connection]
_whitelogger has joined ##openfpga
dj_pi has quit [Ping timeout: 245 seconds]
dj_pi has joined ##openfpga
Bike has quit [Quit: Lost terminal]
rohitksingh_work has joined ##openfpga
<emily>
hi there, my tinyfpga bx arrived ^^ I know it's probably best to use git versions of yosys (especially since I want to work with nmigen) and nextpnr, but is the release version of icestorm ok?
<tnt>
when is the last release from ? I think the U4k support is the last "incompatible" change in icestorm.
<whitequark>
i didn't find a tag, annoyingly
Mimoja has quit [Read error: Connection reset by peer]
Mimoja has joined ##openfpga
Maya-sama has joined ##openfpga
Maya-sama is now known as Miyu
Miyu has quit [Read error: Connection reset by peer]
Miyu has joined ##openfpga
emeb_mac has quit [Ping timeout: 245 seconds]
Miyu has quit [Ping timeout: 252 seconds]
m4ssi has joined ##openfpga
Sprite_tm has joined ##openfpga
Miyu has joined ##openfpga
pie_ has quit [Ping timeout: 252 seconds]
<whitequark>
tnt: just figured out that i don't have to treat each assign as an atomic unit
<whitequark>
i can and should break down muxes into smaller muxes to exploit redundancy there too
<whitequark>
e.g. suppose your high bits depend only on 1 instruction bit, but low bits depend on 3
<whitequark>
*and* it's simpler than the analysis i was doing originally
<tnt>
whitequark: ah yeah, definitely
Asu has joined ##openfpga
<xobs>
Hey all, so I'm having a problem with yosys + nextpnr on Fomu. I'm trying to figure out if it's a logic problem, binning problem, a nextpnr problem, or a yosys problem.
<daveshah>
xobs: What is the problem?
<xobs>
About 10% of the time, I synthesize a bitstream that nextpnr-ice40 says meets timing, but I'm experiencing what really looks like a timing violation over USB -- it's responding with nonsensical values, or it's missing packets, or not automatically ACKing them.
<xobs>
The design is 98% full. I'm still trying to figure out if modifying the `--seed` parameter to nextpnr solves the issue, or if it's a problem with the Yosys synthesis.
<daveshah>
nextpnr's timing model should be pretty conservative (it's based off the iCEcube minimum Vcc, 85 degree model), so binning is unlikely to be the problem
<daveshah>
Although if you have another board it would be interesting to see if the same bitstream fails on both chips
<xobs>
daveshah: the reason why I suspect it might be a binning issue is that about 8% of boards failed to enumerate over USB in the factory, though that might just be crappy assembly.
<daveshah>
Is there any clock-domain crossing or similar going on?
<xobs>
There is. The USB stuff happens in 48 MHz, but then it sends it into a FIFO to get it down to 12 MHz. Then it crosses again to get back up to 48 MHz when it transmits.
<daveshah>
Unfortunately nextpnr's analysis of clock-domain crossing isn't very sophisticated (I'm not even sure how the vendor tools handle this)
<daveshah>
However, a typical FIFO should be fairly robust. You might want to check the "max delay" printed for the cross-delay paths to see if it is likely to cause problems
<xobs>
Let me find a seed that fails, then try that bitstream on two different devices. Good idea -- that'll tell me if it's binning or not.
<xobs>
Okay, yes. I have one board that it works on, and one board that it does not work on. So it's definitely a binning issue.
<daveshah>
Interesting. The first place I'd look would be any cross-clock paths
<daveshah>
Also, hopefully not silly, but make sure Vcc is in spec
<xobs>
The difference between the "working" and "non-working" "Mad delay" builds is ~1ns
<xobs>
I tried putting this design into iCECube, and it refused to even synthesize :(
<xobs>
Is there a way to use the Lattice PNR with Yosys?
azonenberg has quit [Quit: Leaving.]
azonenberg has joined ##openfpga
<daveshah>
In theory yes, but the Lattice Verilog frontend is very fussy about things like the base of parameters that make it a bit of a pain
<daveshah>
You can try a `synth_ice40 -dsp; write_verilog -noattr` and see what icecube makes of it
<daveshah>
I can't remember what else I needed to tweak, but at least one of Synplify or LSE might be happy with this
<xobs>
The Lattice verilog synthesizer couldn't fit my design into an ICE40UP5k, sadly.
<daveshah>
Although it will only consider the worst clock domain, have you tried running the asc file through icetime?
<daveshah>
This will synthesise with Yosys and use the Lattice synthesiser as a frontend only
<daveshah>
In theory there is an EDIF route too, but Yosys' EDIF isn't compatible with whatever flavour Lattice use
<xobs>
Okay, I can confirm that modifying the --seed parameter to nextpnr-ice40 either produces a bitstream that works, or one that does not. So it's the pnr that's causing issues, or the clock domain crossing stuff.
<xobs>
Let me see what icetime thinks of it.
<xobs>
icetime reports 55.79 ns (17.92 MHz), which just looks like it's a path through the vexriscv "jmp" instruction.
<daveshah>
That sounds fine
<daveshah>
I presume that path is entirely in the 12MHz domain?
<xobs>
Correct -- though nextpnr says the max frequency is "13.83 MHz", so you're right in that it's more conservative.
<daveshah>
If you do icetime -m it should be closer to the model nextpnr uses
<xobs>
Same pathway, though now it says the delay is 17.33 MHz.
<daveshah>
I'm slightly surprised at the difference being so high, but it's not part of the problem here either
<daveshah>
Just for curiosity, can you post the full timing report from nextpnr (including the cross clock path reports?)
<daveshah>
Hard to say what is exactly going on without being able to correspond storage_1 though
<xobs>
tnt: you mean the crystal? I can try.
<xobs>
daveshah: The glue between them should just be a fifo wrapped in a migen ClockDomainsRenamer. Should be.
<tnt>
xobs: yes. The UP5k speed it self is nearly twice as fast as what nextpnr think it is, so I'm doubting it's a timing violation, but discrepency between the 12 MHz and the recovered 48 MHz sound more plausible to me.
<tnt>
Although ... re-reading the code now, the fixes by alex should have made that way more robust.
<daveshah>
I can see paths from resetinserter_state[0] to txnrziencoder_next_state[1] (via an inverter on top.v:1597 and some other logic); and also in the other direction from storage_1[1][0] via usb_usb_core_rx_o_pkt_end, usb_usb_core_is_el0, usb_usb_core_tx_i_oe_txpacketsend_next_value0 into a clock enable
<daveshah>
Seems like more than just a grey counter in a FIFO?
<xobs>
So the 48 MHz signal is generated by taking a 48 MHz crystal, dividing it down to 12 MHz with a flop, then running that through a PLL to bring it up to a 48 MHz signal that's reasonably in phase (within 2ns). I should measure the phase difference again. Maybe that's causing issues here.
<daveshah>
Yeah the dividing down with a flop makes me nervous :/
<whitequark>
why the flop?
<daveshah>
iCE40 PLLs have a divider mode (SHIFTREG_DIV_MODE) that can do a divide-by-4
<daveshah>
So it should be possible to get in-phase 48MHz and 12MHz clocks from one PLL
<whitequark>
^
<xobs>
Because the lowest frequency the PLL will generate is 16 MHz, which is above the 12 MHz that I need.
<daveshah>
I think SHIFTREG_DIV_MODE will still work here
<tnt>
but with div-by-4 the pll would generate 48M
<tnt>
I'm not sure you get can get output A with division and output B without though ?
<whitequark>
if you generate in-phase 12 MHz you can just use the original 48 MHz as-is
<whitequark>
among other things
<daveshah>
tnt: ah yes, was confusing with fancier PLLs
<daveshah>
but you should be able to generate 24MHz and then use GENCLK_HALF output mode
<daveshah>
with whitequark's suggestion for the 48MHz
<xobs>
There's that odd divide-by-7 option, I thought.
<tnt>
yeah, it can do 4/5/7
<tnt>
5 being for hdmi and 7 for fpdlink IIRC
<xobs>
And the in-phase option only works if I run the PLL through... G6 I think? Which I didn't sadly.
<whitequark>
are you sure?
<tnt>
you can' tuse a _PAD pll and use the 'pass-through', but you should still be able to use a _CORE one and take its input from normal routing.
<tnt>
But then I guess your source clock will go from global net, to normal routing to the PLL and so it won't be perfect
<daveshah>
There shouldn't be much normal routing though
<xobs>
That's the idea I've been operating under. However I'll double check.
<whitequark>
also you can maybe use fine delay adjustment if it comes to that
<tnt>
xobs: but you already have that imperefection in your scheme as well :p
<whitequark>
the PLL and global net is fixed in location
<whitequark>
so pnr should not vary much ther
<tnt>
mmm, the input global net isn't locked.
<xobs>
I do know that the datasheet says that PLLOUT must be between 16 and 275 MHz.
<tnt>
(but could be locked manually)
<xobs>
I'm already using `FDA_FEEDBACK` and `FDA_RELATIVE` to get the phase as close together as I could.
<xobs>
whitequark: good point on the fixed position. Maybe that's not so much the issue here.
<tnt>
but I doubt that divide by FF is the root cause. The cross clock path highlighted by daveshah seem much more concerning.
<daveshah>
xobs: just playing with the Radiant PLL wizard, no error is given if GENCLK_HALF is used to create a 12MHz clock
Asu has quit [Read error: Connection reset by peer]
<xobs>
daveshah: I was noticing that. Strange that the datasheet says that's not valid. Also, icepll won't generate a PLL with a 12 MHz output.
<daveshah>
Yeah, icepll doesn't know about the GENCLK_HALF mode
<daveshah>
but telling icepll to generate a 24MHz output then changing the output type should be fine
<xobs>
Curiously, iCECube2 doesn't use GENCLK_HALF mode either.
<xobs>
daveshah: so you're saying that the cross-domain path ought to just have the fifo, but somehow that timing path is getting other logic put into it?
<daveshah>
Yes, or you have accidentally created a cross-domain path somewhere
<tnt>
digging in the path a bit more it just seems to be the fifo 'output register' (clocked from 48 MHz) going into the 12 MHz logic.
<daveshah>
Ah, that sounds fine
<tnt>
which I would expect ... (it's a 2-level deep fifo so it's just a couple of registers).
<tnt>
doesn't mean there isn't other paths though
Asu has joined ##openfpga
<xobs>
Let me see if I can't look at the phase between the two domains again. Maybe it changes depending on how things are placed, and the phase just ends up too large to meet timing on this part.
<tnt>
if you cross only using FIFOs, the phase shouldn't matter at all in the first place.
<whitequark>
it might matter because it's only a 2 level deep FIFO?
<tnt>
mmm, if the 48M block are operating properly, it shouldn't. They pass bytes, so there should be a write every 32 cycles in average, and it reads as soon as one is available.
<whitequark>
ahh
<whitequark>
why does this use a FIFO anyway?
<whitequark>
shouldn't this be something like blind synchronizer or ping pong synchronizer?
<whitequark>
latter probably
<tnt>
it should yeah. The first version of the core was pretty much just wrong, just pushing bits with just multireg between 48M and 12M, except the bits came in at a 'recovered' 12M rate and were consumed at a local 12M rate, so ... obvious issues.
<whitequark>
yeah, I've heard things about this core...
<tnt>
as a quick hack to prove this was an issue I added a 1 bit fifo as an elastic buffer.
<tnt>
then alex came in an properly pushed the 8:1 into the 48M domain.
<tnt>
but I guess he used a fifo just as an easy solution since it exists as a primitive in migen.
<whitequark>
but other things exist as primitives too
<whitequark>
genlib.cdc i think
<tnt>
Ah well ... that just shows my ignorance :p
<xobs>
genlib.cdc sounds like a good place to put them.
<xobs>
This is my first introduction to migen, and first major HDL project. So I've got a lot to learn. Might be time for another refactor.
<xobs>
It looks like the proper solution would be to replace it with a pair of BusSynchronizers then?
<whitequark>
I think so
<tnt>
xobs: I think the flags should just be independent PulseSynchronizer
<tnt>
The BusSynchronizers doesn't provide a strobe out, does it ?
pie_ has joined ##openfpga
<xobs>
Doesn't appear to provide one, no.
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
<zignig>
xobs: port it to nmigen , no really :)
<zignig>
minerva is a risc-v and everyone in the entire universe (me) wants valentyusb in nmigen...
<whitequark>
i might implement an usb stack to be used together with boneless if boneless runs at 48 MHz on UP5K
<whitequark>
possibly derived from valentyusb
<zignig>
yay!
<whitequark>
then it doesn't need any CDCs
<xobs>
zignig: at this point I'm just trying to get it stable with what we have now.
<zignig>
yeah , it weighs in a 27 ish Mhz at the moment.
<zignig>
xobs: indeed ;0
<zignig>
whitequark: i'm having some preponderance on how to get macros going, the Instr is bound to the coding and I'm not sure how to freeform a "<NAME> text_operand,text_operand"
<zignig>
how were you going to do the psuedo instructions , this seem like and extenstion of that.
<whitequark>
zignig: i don't remember actually, i'll need to swap that in
<whitequark>
not gonna happen until i'm done with whatever i'm doing with yosys right now
<zignig>
oh yes , there is no expectation on my part for you fix stuff for me , I'm just happy that the neat_instrction_set is because I wanted a text assembler.
* zignig
<grin>
<zignig>
tonights adventure is to port the serial interface and the HEX reader to _base_ level v3 assembler.
Asu has quit [Remote host closed the connection]
Asu has joined ##openfpga
<whitequark>
hopefully JST would help with that
<whitequark>
though... unfortunately there is no way to refer to a label in assembly yet
<zignig>
i'm just using chained CMP (->CMPI) on ascii values for now , but the jump tables will be neat , need to try a window as well.
<whitequark>
something like .table; .offset label; .end
<zignig>
yeah , so far the directives are decorated functions with access to the Assembler , not sure if it's good but some of it works.
<zignig>
I would prefer to use operands for everything so resolution of symbols is internal and consistant.
<whitequark>
well, the assembler is designed so that anytime it encounters a function in the structured input, it calls it and passes it a resolver
* zignig
thinks metaclasses are quite confusing.
<whitequark>
they are, yes
<whitequark>
there's no especially good reason to use metaclasses like i did
<whitequark>
i just liked how short it is
<zignig>
I'm still unraveling your code , but is is elegant ( except for the eval in Instr which is cursed and slightly radioactive )
<whitequark>
na, that eval is perfectly fine
<whitequark>
it's mostly there so that __init__ works well
* zignig
puts his lead lined gloves back on.
<whitequark>
lol
<whitequark>
it could certainly use a dict for everything except __init__
<whitequark>
but i thought, well, it's there anyway, might as well make it a bit faster
<zignig>
and the opcode.py is so pretty.
<whitequark>
yeah
<zignig>
my long term plan is to have a nmigen interface via a resident boneless , but that is months off.
<zignig>
so I can interactivly add Elaboratables to the FPGA and the boneless will background write the new images and reboot into it.
<whitequark>
ahhh
<whitequark>
that doesn't seem too hard?
<zignig>
need a working bootloader and a WARMBOOT.
<whitequark>
right
<zignig>
... and the assembler needs macros and stuff.
<whitequark>
sure
<tnt>
The BX is a bit annoying in its lack of memory.
<whitequark>
i'll fix the assembler, just when i get to the software side of boneless again
<whitequark>
since right now i'm busy fixing inefficiencies in yosys
<whitequark>
it's impossible to optimize boneless when any change means it gains or loses 100 LUTs for no reason
<zignig>
tnt: I have considered a mux that uses all the BRAM and the balance of the 'memory' is in flash.
<zignig>
whitequark: ;/ , hence the yosys work ...
<xobs>
So in using the GENCLK_HALF trick, the phase delay between clk12 and clk48 goes down to 1.2ns, and seems to stay there regardless of pnr. I still feel weird running the PLL outside of the range the datasheet says it'll run at.
<zignig>
xobs: strech it until it breaks, then you know where the edges are....
<whitequark>
xobs: the datasheet is just badly written
<tnt>
xobs: you're not
<whitequark>
they mean the minimum freq is 16 MHz *before* the divider
<whitequark>
lattice datasheets are wrong all the time, eg SB_IO circuit is completely broken
<whitequark>
s/lattice// i guess
<xobs>
whitequark: I believe that. I'll keep that in mind!
<xobs>
zignig: that's a good idea. I'll try that on Monday if this test passes tonight.
<zignig>
xobs: nice work on the FOMU btw , a _whatever_ usb device will be cool.
<xobs>
zignig: thanks! once I get this all sorted out I'll need to improve it to allow more than 2.5 endpoints. That'll really open up the possibilities. ...and of course get hardware multiply back into the cpu. And maybe an MMU.
<zignig>
I have been thinking about a every 80's machine emualator that presents a webcam and a serial console.
* zignig
hails 8bit.
<whitequark>
webcam?
<whitequark>
ah, no, that's not viable to do on a fomu at all
<zignig>
a webcam usb endpoint is recognised bus most OS's , medium res video device...
<whitequark>
yeah and you need MJPEG
<zignig>
/bus/by/
<whitequark>
(or worse)
<xobs>
That wasn't the problem. Got another usb failure, even though the phase hasn't changed between the two clock domains.
<zignig>
whitequark: well that becomes many LUTS. grrr
<whitequark>
usb is a really bad way to do this
<whitequark>
also, anything a fomu can do, can be done better on that machine itself
<tnt>
zignig: mmm, actually you could stream uncompressed 160x120 8 bit video.
<zignig>
whitequark: encapsulation on a FPGA has some advantages.
<xobs>
Now I'm looking up the QuickCam protocol...
<whitequark>
zignig: you lose most of them when you add USB to the mix
* zignig
has been battling modbus this week , DAMN all protocols
<zignig>
whitequark: you really dislike USB don't you , I suspect you have read all the relevant docs ...
<xobs>
Since the pll phase wasn't the issue, I'll look into replacing that asyncfifo with a BusSynchronizer and see if that fixes things.
<tnt>
16 bit cpu + usb core + uart + spi fits in ~ 1500 LCs. that leaves some margin for useful logic.
<whitequark>
zignig: not all... there are far too many
<zignig>
xobs: can you move the entire stack to 12Mhz and just start with low speed to get it going ?
<whitequark>
and i certainly do not understand every part of it, though i doubt anyone in the entire world does
<whitequark>
i understand more than enough to hate it though
<whitequark>
one of the worst protocols ever designed
<xobs>
zignig: I can on this test PCB -- I did wire up that resistor.
<tnt>
zignig: huh, no, serdes part has to run at 48M
<zignig>
whitequark: multiple conflicting "standard" defs. YAY
<zignig>
I currently have a FTDI bridged onto my tinybx , so I can eventually debug USB from the inside.
* zignig
le sigh
<tnt>
reminds me I need to dig up my BX and replace the bootloader on it with mine.
<zignig>
tnt: I'm aiming towards a console 9600,8,n,1 Mwhahahahahah
<xobs>
I had to remove the uart from Fomu because it didn't fit anymore.
<xobs>
Part of the reason I'm space-constrained is that I've got four hardware breakpoints for source-level debugging.
<whitequark>
do you need four?
<whitequark>
two are enough for all use cases i think
<xobs>
Two are enough, but I ran into enough problems debugging cortex machines with only two, so I thought I'd splurge.
<emily>
And then I get the same when resetting it when in that port.
<emily>
so it's still broken, but less weirdly.
<whitequark>
i never trusted these barely-working usb bootloader things
<whitequark>
emily: perchance do you have an usb 2 hub?
<whitequark>
or really any hub
<zignig>
emily: can we get platform , os and installs ?
<emily>
whitequark: not to hand :/
<emily>
zignig: x86-64 nixos linux, so "installs" is not even an answerable question I'm afraid. but I have a pretty barebones setup; if anything's interfering i suspect it's connman/iwd thinking it's a modem
<zignig>
emily: conmann is pure eveil as far as i'm concern , return to ifupdown at all costs....
<whitequark>
if you can grab a wireshark log of usb traffic i can tell if it's software or hardware problem
<zignig>
lsusb with the tiny in bootloader should yield : Bus 001 Device 047: ID 1209:2100 InterBiometrics
<emily>
whitequark: looks like that runs into the eternal problem of "adding yourself to a group in linux on the fly is annoying" ~.~
<emily>
(for raw USB capture)
<whitequark>
indeed it does
flea86 has joined ##openfpga
<zignig>
*reboot
<whitequark>
i usually do something like `sudo login`
<xobs>
sudo -i
<emily>
wireshark also didn't like being run as root :) but I just did some setfacl horrors instead
<zignig>
or you could just run every thing as root with an open telnet port.
* zignig
hands emily a exorcizing widget.
* zignig
reallife(tm) interjects.
* zignig
averts crisis
<emily>
ok, it was tlp autosuspending the USB device
<emily>
and tinyfpga bx not handling that correctly, I guess
<whitequark>
in theory, an usb stack could be made as a "macro" so it's drag and dropped into your design
<whitequark>
in practice, i don't think currently our tooling handles that well
<whitequark>
emily: i *think* EX is a 6-layer board and BX is 4-layer
<whitequark>
yeah
<daveshah>
I got a PoC of something like that working on ECP5 recently, using the new JSON export, but it's still very rough and a few months off something end-user-ready
<daveshah>
Basically adding some LED GPOs to a picorv32 macro
<whitequark>
cool!!
<whitequark>
i really want a boneless macro
<whitequark>
maybe even hand-placed?
<daveshah>
Yeah, that would work
<daveshah>
These aren't moveable macros yet, fully locked placement and routing
<mwk>
how would movable macros even work?
<mwk>
I mean, there are blockram columns and shit in FPGAs, no two locations are truly the same
<daveshah>
Yeah, that's exactly the problem
<mwk>
I've spent some time thinking of this and didn't come to any useful conclusion
<whitequark>
logic-only macros?
<daveshah>
Yeah, the current relative placement constraints would be good for logic-only macros for the most part
<mwk>
as in, you assume W×H rectangle containing only CLBs?
<whitequark>
an USB PHY or boneless would fit
<whitequark>
yes
<mwk>
that would work until your macro gets large, yes
<whitequark>
well if it's so large it doesn't make sense to make it a macro at all
<daveshah>
Xilinx has some stuff like this in RapidWright
<daveshah>
But it's for small-to-medium blocks, I think I saw someone using it with a small RISC-V core
<daveshah>
For big blocks a fixed macro usually makes more sense
<zignig>
nextpnr needs a floor planner.
<mwk>
nextpnr needs many things :(
<mwk>
but hm
<mwk>
blockram/DSP columns are *dense* on xilinx devices
<mwk>
it's actually rare to find >4-column stretch of logic
<zignig>
perhaps we should throw wads of cash at bunny and get a openlogic chip.
* mwk
starts looking at random series 7 devices
<zignig>
i'm just really impressed that Master Wolfs work has spawned a "don't need 6Gb of diskspace" movement.
<zignig>
I recently did not push the reset button in time because nmigen was too quick for me.
* zignig
bits all goodnight, brain is travelling NNW atm.
ironsteel_ has quit [Quit: Ex-Chat]
<whitequark>
tnt: the second dataflow analysis works *beautifully*
<mwk>
hrm
<mwk>
so I have a bunch of long clock lines, spanning the whole die vertically / horizontally
<tnt>
whitequark: damn, you're getting through this pretty quickly :)
<whitequark>
tnt: i spent the last 5 years writing the same compiler over and over
<whitequark>
and i just wrote it again
<tnt>
lol
<mwk>
they're driven from the middle, and there's a special config bit at each end that lights up if any of the 32 lines in the bunch is used
<mwk>
I'm wondering wtf it is for
<mwk>
do you need to provide some sort of active termination for high-quality long clock lines on die?
<whitequark>
maybe power saving?
<tnt>
that'd be my guess.
<mwk>
well, obviously
<mwk>
the question is what it controls
<whitequark>
oh
<mwk>
first, it's in a dead end
<mwk>
past all clock lines users
<mwk>
second, it's shared for all 32 global cock lines in the vertical spine
<mwk>
*clock
<mwk>
ah screw that, who cares
<tnt>
mwk: Are you looking at the actual physical die ? (I'm missing some context here)
<mwk>
tnt: I'm fuzzing clock routing bits on an FPGA
<mwk>
feeding random designs to bitgen and looking at what it shits out
<tnt>
ok, so that might just turn on the buffers globally for that spine.
<mwk>
but buffers are in the middle, and there are plenty of bits in that area already, and they're per-line as expected
<mwk>
the strange extra bits are at top/bottom of the device, at global line ends, and they're tied between all 32 global lines
<mwk>
ie. bit lights up if any global buffer at all is used
<mwk>
that's the main verical spine, but horizontal clock rows have something similar as well
<mwk>
an extra bit at the far left / far right column that lights up if any horizontal buffer in a given half-row [left or right] was used
<mwk>
anyway, who cares... it's just a bit I need to light up if I use any routing in the area, simple enough to handle in software, I was just curious...
rohitksingh_work has quit [Read error: Connection reset by peer]
dh73 has joined ##openfpga
genii has joined ##openfpga
genii has quit [Remote host closed the connection]
flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
noobineer has quit [Ping timeout: 250 seconds]
Miyu has quit [Remote host closed the connection]
Miyu has joined ##openfpga
noobineer has joined ##openfpga
Asu has quit [Ping timeout: 245 seconds]
Asu has joined ##openfpga
genii has joined ##openfpga
m4ssi has quit [Remote host closed the connection]
<cr1901>
tnt: Forgot to mentiion this a few days ago re: your 48MHz target for icebreaker I understand this is desirable if you want max throughput, but I can vouch personally that I've run an STM32 at the lowest possible clk speed (16MHz) and have gotten acceptable results using USB CDC and MSC
<cr1901>
So maybe break up the PHY portion and your CPU portion into separate clk domains to make things less stressful?
Jybz has joined ##openfpga
emeb has joined ##openfpga
Jybz has quit [Quit: Konversation terminated!]
Miyu has quit [Ping timeout: 245 seconds]
<tnt>
cr1901: Oh yeah sure, atm instead of my own core I used a picrorv32 clocked at 24 MHz and I can stream several Mbits of isochronous data.
<tnt>
cr1901: mostly I want 1 clock domain to not pay the price of the bus interface cross clock and also to free up the PLL.
cr19011 has joined ##openfpga
cr1901 has quit [Ping timeout: 244 seconds]
cr19011 has quit [Read error: Connection reset by peer]
zkms has quit [Quit: zkms]
zkms has joined ##openfpga
zkms has quit [Client Quit]
zkms has joined ##openfpga
zkms has quit [Client Quit]
zkms has joined ##openfpga
cr1901 has joined ##openfpga
Richard_Simmons3 has joined ##openfpga
Richard_Simmons has quit [Ping timeout: 276 seconds]
Miyu has joined ##openfpga
Laksen has joined ##openfpga
Miyu has quit [Ping timeout: 264 seconds]
Laksen has quit [Quit: Leaving]
Asu has quit [Read error: Connection reset by peer]
Bike has joined ##openfpga
genii has quit [Remote host closed the connection]