sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
<cr1901_modern>
Somebody emulated an ARM on an Atmega... oh nevermind, we're talking about the same thing
<whitequark>
it would probably take decades to build libreoffice on that
mumptai has joined #m-labs
<cr1901_modern>
I may have to build Firefox from source. Not looking forward to that.
<rjo>
i was very proud when my first ardour builds on mips took 9h and succeeded.
<whitequark>
huh, mips
<whitequark>
my first and almost only mips system was a video ad distributed in a magazine locally
<whitequark>
i.e. you crack the paper magazine open and it starts playing some 30-sec clip about vodka or something
<whitequark>
naturally, i ported linux to it
<cr1901_modern>
That sounds "fun".
<whitequark>
nah, just a boring mips board
<whitequark>
soldering wires for an SD card to the LQFP with 0.3mm spacing was the hardest part
<whitequark>
but it's doable
<cr1901_modern>
I can't solder SMD components. At all.
<cr1901_modern>
which is something I'm constantly worrying about since I want to start using CPLDs on the PCBs I make
<cr1901_modern>
Someone recently made their own BGA ARM board and ported Linux to it, and posted the results on Reddit. They say Linux isn't difficult to port, but the current documentation on how to do it sucks.
<whitequark>
meh. use the source
<cr1901_modern>
I'd probably lose my patience wondering why the CPU is crashing in the bootstrap code if I tried a port lol
<whitequark>
so get JTAG
<cr1901_modern>
I should feel bad (and do) for not knowing that.
<cr1901_modern>
Interesting, according to a quick Google search, MIPS actually documents its JTAG extensions
<whitequark>
ARM does
<whitequark>
well, most vendors do, really
<cr1901_modern>
Except FPGA vendors, apparently
<whitequark>
they also do.
<whitequark>
bitstream, not always, but JTAG? sure
<cr1901_modern>
I'll look harder for Xilinx documentation tomorrow (fatigue is hitting hard), and keep what you say in mind.
<cr1901_modern>
There's a project (not OpenOCD) that is trying to create a JTAG programming/debugging library. It attempts to abstract away the various cables and bitstreams using clean separate interfaces.
<cr1901_modern>
And I can't remember the name of it for the life of me
<cr1901_modern>
Ah well, I'll look for it tomorrow
<GitHub37>
[artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vmqam
<GitHub37>
artiq/new-py2llvm f417ef3 whitequark: Make binop coercion look through CoerceT nodes....
<GitHub39>
[artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vmqAV
<GitHub39>
artiq/new-py2llvm bdcb241 whitequark: Add basic IR generator.
<whitequark>
actually no... i'll have to expand most expressions at IR level
<whitequark>
lambdas and comprehensions have scopes, calls have to be lowered to invoke instructions
<whitequark>
thankfully that is not actually more work than doing it at the LLVM level. more class definitions, perhaps
<mithro>
Has anyone worked on / thought about DDR3 on a Spartan 6? The misoclib/mem/sdram/phy/s6ddrphy.py has a "S6DDRPHY only supports DDR, LPDDR and DDR2" comment
<sb0_>
mithro, I would not recommend it
<sb0_>
DDR3 requires fast and precise timings that are not very compatible with the crappy spartan6 iodelays
<sb0_>
use 7series if you need ddr3
<mithro>
sb0_: It seems to be working fine with the Xilinx generated MCB thingy
<sb0_>
yes, using undocumented features and gross hacks
<mithro>
:-/ - I have a board with a Spartan 6 and DDR3
<mithro>
sb0_: so, what would be your suggestion as the best way to move forward? Try to add similar hacks into the S6DDRPHY, wrap the Xilinx MCB?
<sb0_>
depends on your patience :)
<sb0_>
wrapping the xilinx mcb is probably faster and less painful, but dirty
<sb0_>
rewriting it requires understanding a number of weird, obscure and most certainly buggy spartan6 details
<sb0_>
do you absolutely need that board?
<mithro>
sb0_: yeah - its the board I was showing the other day
<mithro>
sb0_: when you say *requires* does that mean "actually required to make the ram function" or "required to get DDR3 throughput be better then DDR2"? IE Would "under clocking" the ram work?
<sb0_>
no, it would not, DDR3s have DLLs that can only operate in a small frequency region
<sb0_>
disabling the DLLs makes the RAM extremely slow
<sb0_>
(10MHz or so)
<sb0_>
DDR3 on Spartan-6 is stupid, it is not faster (as the FPGA IO rate is the limiting factor for DDR2 already) but it is more complicated
<cr1901_modern>
felix_: I think that might've been it; I remember that one of the developers of the project I'm thinking of managed to reverse-engineer the Digilent/Xilinx cables.
<mithro>
Anyone know if there is a way to use the Xilinx JTAG cable as a virtual UART for initial testing?
<sb0_>
with misoc? you'd have to develop a "UART" that uses the bscan primitive on one end, and drivers on the PC side
Gurty has joined #m-labs
Gurty has joined #m-labs
<mithro>
Gah, I don't really have a good location to attach a temporary UART on this board - both my USB->UART devices don't support 1.5V signalling levels :/
tija has joined #m-labs
<cr1901_modern>
mithro: I think rjo has a project trying to do just that
<cr1901_modern>
i.e. UART to JTAG bridge
<cr1901_modern>
But he can explain it better than I could lol
<mithro>
what would be the quickest way to get a misoc bios to just echo out "a" on the uart every second?
<stekern_>
sb0_: because llvm needs/requires a maintainer committed "full-time" to llvm work before they accept any ports upstream
<whitequark>
"full-time" is a bit of exaggeration, but the bottom line is, breakage must be promptly fixed, and refactoring will generally be made without regards to the specific needs of your target
<GitHub65>
[artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/vms37
<GitHub142>
[migen] sbourdeauducq pushed 1 new commit to master: http://git.io/vmsRc
<GitHub142>
migen/master 52bdc29 Sebastien Bourdeauducq: mimasv2: style, consistency with other boards
<rjo>
stekern_: what could be done to get to full-time support (or at the level whitequark defines it)? can we pool together (the ones commercially backing and using or1k) to do that?
<rjo>
fwiw m-labs/m-labs should not need to carry the entire load.
<whitequark>
hm?
<rjo>
well. if we can get other commercial users backers of or1k to chip in, you have more time to work on artiq!
* rjo
has ise chugging away building 120 bscan_spi bitstreams.
<whitequark>
ah, true
<whitequark>
are there commercial users of or1k?
<sb0_>
I assume that risc-v still sucks?
<sb0_>
not upstream either. ha.
<sb0_>
plus as i mentioned before, pick a kc705-sized cpu core or CPI >3. "we are, however, Berkeley" ...
<whitequark>
is the pipelined verison so large or what?
<sb0_>
yeah. and just pipelined, not even OOO
<sb0_>
the CPI >3 version is a stupid fsm-based design that the author still managed to get larger than lm32
<whitequark>
what do you think of lowrisc
<sb0_>
that you put it through a synthesizer and it does not work?
<whitequark>
harsh
<sb0_>
and well, sure you can make CPI >3 FSM toy implementations or experiment with architectures that bloat the design to the extreme, but risc-v has zero usable implementation right now
<sb0_>
though everyone likes to boast on the mailing list on how good their design is which will be released "soon"
<sb0_>
smells like a nasty mix of opencores and academia
<whitequark>
hah
mumptai has joined #m-labs
mithro has joined #m-labs
<GitHub179>
[migen] sbourdeauducq pushed 1 new commit to master: http://git.io/vmGpL