<cladamwa>
wpwrak, i'm reading carefully your words in threads. regarding to two status LED ("booted" and "rendering"), you said 'only one would stay', does this one is the for which one? How we call that one meaningfully?
<wpwrak>
i would keep only "booted". "rendering" isn't so useful. particularly now that we have an army of indicator leds
<cladamwa>
my last 20120120 version is 3*3*2 matrix, so I'll change their 'marked text' firstly.
<kristianpaul>
I'll try to mofe to F16, will not been soon, i still need space to backup and reinstal and deal with bios minor issues :)
<kristianpaul>
gn8 !
<kristianpaul>
s/mofe/move
<cladamwa>
kristianpaul, n8 !
<cladamwa>
wpwrak, I'll remove D3 then keep D2 be as "booted" status same as rc3 for like 'dimly lit' condition.
<wpwrak>
cladamwa: (matrix size) will you grow it to 3*4*2 ?
<wpwrak>
(dimply lit) yup. i thought you'd want that. it served us well ;-)
<cladamwa>
yes, this condition is super usefull when first reflash to know if soldering good or not, so maybe i just mark text as 'booted' in sch firstly.
<cladamwa>
wpwrak, you wanted 3*4*2? i didn't see how many that we fill them all. ;-O
<wpwrak>
wolfspraul: btw, sebastien is planning to use the ffmpeg library, so that we can use frames from images in effects as well. i already warned him about patent-poisoned codecs. does ffmpeg sound okay to you, as long as it's compiled without encumbered codecs ?
<wolfspraul>
sure, why not
<wolfspraul>
the patented stuff is h.264, mpeg
<wpwrak>
cladamwa: we currently have 16. so 3*3*2 would be enough (with two to spare). you may want to reserve a pin for another column, though. in case we need more in the future.
<wolfspraul>
I think we can feel relatively safe with Ogg, WebM
<cladamwa>
wolfspraul, your 'why not' is for my 3*4*2 question?
<cladamwa>
ha..seens wpwrak really wanted a 3*4*2 matrix though. ;-)
<wolfspraul>
whatever wpwrak wants is what we want
<wolfspraul>
:-)
<wolfspraul>
that's 6 w there!
<wpwrak>
;-))
<cladamwa>
omg ;-O, okay.
<cladamwa>
wpwrak, btw, from your threads, i didn't see an experiment about DC in (overriding with bjt came from your idea), didn't you?
<wpwrak>
cladamwa: no, i didn't experiment with that. i don't have any FETs.
<cladamwa>
since I don't want to use another BJT we don't have that new part in rc3 but FETs yes we have had it (i.e. Q1 2N7002).
<wpwrak>
ah yes, that circuit is also something that needs checking. see if it actually works. afaik, that's never really been tested.
<wpwrak>
(2N7002) whatever works ;-)
<cladamwa>
seems that I need to do this expriment or I send part to you? since how I use fpga pin via overriding to control it?
<cladamwa>
mmm...letmme think
<wpwrak>
you do it ;-) you could connect to one of the ports you can control. actually, i should add an override feature to the led matrix controller anyway. then you could use that
<cladamwa>
i think i can do this myseld by using 3.3V and GND to simulate fpga pin to overriding. yeah !
<wpwrak>
hehe ;)
<cladamwa>
s/myseld/myself
<wolfspraul>
what was the (current) end result of the crowbar discussions?
<wpwrak>
hmm, in theory, the 270 Ohm would be more correct than 220 Ohm, particularly considering that it has a slightly lower Vf than my leds. but that assumed that the I/O pins have an Ron of 0 Ohm.
<wolfspraul>
and all the other 5V protection ideas...
<wpwrak>
wolfspraul: joerg agreed that it's a good idea to keep 5 V away from 3.3 V
<wolfspraul>
yeah but there was a mail with a whole list of ideas?
<wpwrak>
the jumper would do that in cases where one doesn't need 5 V at all
<wpwrak>
the crowbar would do it also in cases where 5 V is around. so it's better
<wpwrak>
but also more complex
<wpwrak>
not sure if anyone feels strongly enough about it to implement and test that crowbar
<wpwrak>
the jumper, on the other hand, is as easy as it gets ;-)
<wolfspraul>
ok
<wolfspraul>
if most people never use 5V, the jumper devalues the crowbar as well
<wolfspraul>
because if we ship boards with the jumper off, then no 5V in the first place
<wpwrak>
yeah
<wolfspraul>
ok, I see it's still at the same state
<wolfspraul>
:-)
<cladamwa>
wpwrak, with rough an Ron of 0 Ohm should be enough to esablish this LED ON/OFF status, so if 270 Ohm then we stick this.
<wolfspraul>
alright then, let's first settle the leds, then onto j21/j22
<wpwrak>
how big is Ron typically ? i thought it was relatively large ? if it's >= 20 Ohm, then 220 Ohm is okay. else, we should use 270 Ohm.
cladamw [cladamw!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
mumptai [mumptai!~calle@brmn-4dbc9713.pool.mediaWays.net] has joined #milkymist
rejon [rejon!~rejon@li382-141.members.linode.com] has joined #milkymist
cladamw [cladamw!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
cladamw [cladamw!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
Martoni [Martoni!~chatzilla@arc68-5-88-188-247-92.fbx.proxad.net] has joined #milkymist
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
<Fallenou>
lekernel_: I successfully synthetized modified (just lm32 + sram) milkymist-ng using migen, either in console or in ISE using generated source code. But afterward I cannot select "ISIM" as a simulator from ISE
<Fallenou>
I tried running directly "isimgui", but I cannot find how to use it more than a text editor, I can only open verilog files
<Fallenou>
simulation start/stop menus are disabled
<Fallenou>
"grey"
<lekernel_>
use "fuse" in command line
<lekernel_>
I never use the gui
<Fallenou>
a year or so ago I used modelsim gui it was OK
<lekernel_>
modelsim != isim
<Fallenou>
I could use iverilog+gtkwave but iverilog does not know spartan6_jtag block or spartan6 DSP block (for multiply)
<Fallenou>
so it would need a few modifications
<lekernel_>
iverilog has bugs that crash it when you load lm32
<lekernel_>
same for gplcver
<lekernel_>
you can have a look at verilator, I haven't tried it
<lekernel_>
(and the author seems quite responsive for fixing problems)
<Fallenou>
ok I will start on the fuse track then
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
<Fallenou>
lekernel_: I have the same bug you had with isim "ERROR:HDLCompiler:1654 - "../verilog/lm32/lm32_multiplier_spartan6.v" Line 47: Instantiating <D1> from unknown module <DSP48A1>"
<lekernel_>
Fallenou: use the normal lm32_multiplier.v (without _spartan6)
<lekernel_>
they're compatible
<Fallenou>
ok
<Fallenou>
now it complains about DCM_SP
<Fallenou>
I will just comment it
<Fallenou>
and put a simulated clk
<lekernel_>
yeah don't bother with DCM's in simulation
<lekernel_>
they will just make everything more complex... use just one clock
<Fallenou>
ok nice it compiled
<Fallenou>
and generated binary does not segfault
<Fallenou>
\o/
<Fallenou>
oh, and I can run the gui with ./binary -gui
<Fallenou>
and now all start/stop wave stuff are enabled
* Fallenou
excited
<lekernel_>
I'd recommend you use $display ... looking at waveforms manually is a pain
<Fallenou>
humm I've put reg clkfx_sys_clkout = 1; always #5 clkfx_sys_clkout = ~clkfx_sys_clkout; but the clk stays at 'z'
<lekernel_>
(and someday we'll hopefully have something more powerful than $display... myhdl is pretty nice for that, we should copy the relevant bits into migen)
<Fallenou>
ok but I need waveforms too
<Fallenou>
it really gives a more accurate idea of what's going on
<lekernel_>
initial clkfx_sys_clkout = 1;
<lekernel_>
and remove the =1 at the reg
<Fallenou>
ok
<Fallenou>
weird the reset went down anyway after a few us
<Fallenou>
how can I speed up the simulation ?
<Fallenou>
it's damn slow
<lekernel_>
you can remove the reset counter too... and use a delay
<lekernel_>
also 1 clock of reset is enough
<Fallenou>
yep ok
<lekernel_>
verilator is probably much faster than isim - if you can get it to work
<lekernel_>
which isn't always easy
<Fallenou>
ok I was looking at clkin , that's why I got "z'
<lekernel>
(it's often even faster than modelsim)
<Fallenou>
(not clkout)
<Fallenou>
now I need a few instructions in sram and I'm good to go
<Fallenou>
$readmemh should work I guess
Thihi [Thihi!~tapiob@vip.mikrobitti.fi] has joined #milkymist
<Fallenou>
I should have a working simulation environment by tonight :)
elldekaa [elldekaa!~hyviquel@adm02.insa-rennes.fr] has joined #milkymist
<lekernel>
you can use $readmemh, or init= from Migen
<lekernel>
of course, if you're hand-editing the generated verilog, using init= becomes messy *g*
<Fallenou>
yep ^^"
<Fallenou>
I don't want to rerun migen, it would overwrite my changes
wolfspraul [wolfspraul!~wolfsprau@114.241.252.33] has joined #milkymist
cladamwa [cladamwa!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
<Fallenou>
lekernel: do you know why sram0_wishbone_adr_i has a kind of "prefix" wich is not "all 0" ?
<Fallenou>
eventually frag_sram0 end up with the good address (0 then 0x1 0x2 etc)
<Fallenou>
but it's accessed with a weird address
<Fallenou>
from a wishbone point of vue
<Fallenou>
first accessed wishbone address is 0x00218000
<Fallenou>
I would have expected 0x00000000
<lekernel>
check lm32_include.v
<Fallenou>
bbl eating
DJTachyon [DJTachyon!~Tachyon@ool-43529b4a.dyn.optonline.net] has joined #milkymist
cladamw [cladamw!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
azonenberg [azonenberg!~azonenber@cpe-67-246-33-188.nycap.res.rr.com] has joined #milkymist
rejon [rejon!~rejon@li382-141.members.linode.com] has joined #milkymist
<Fallenou>
lekernel: looking at the first address on I_ADR_O it's trying to fetch 0x00860000 which is the EBA_RESET
<Fallenou>
somehow it gets translated into 0x00218000
<Fallenou>
ok got it
<Fallenou>
860000 / 4 == 218000
<Fallenou>
I_ADR_O jumps 4 by 4 cause it's addressing bytes, but wishbone divides by 4 for SRAM because it's addressing words
<lekernel>
yes, wishbone address is in 32 bit words with migen
<Fallenou>
oh ok so not just for SRAM
<Fallenou>
for all the slaves
<lekernel>
no, it's only in bytes inside LM32 (but the two LSBs are hardwired to 0)
Alarm [Alarm!~chatzilla@70.58.7.93.rev.sfr.net] has joined #milkymist
antgreen [antgreen!user@nat/redhat/x-avzsgibgitayzenk] has joined #milkymist
Alarm [Alarm!~chatzilla@70.58.7.93.rev.sfr.net] has joined #milkymist
mumptai [mumptai!~calle@brmn-4dbc9713.pool.mediaWays.net] has joined #milkymist
Alarm [Alarm!~chatzilla@70.58.7.93.rev.sfr.net] has joined #milkymist
Alarm [Alarm!~chatzilla@70.58.7.93.rev.sfr.net] has joined #milkymist
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
<Fallenou>
lekernel: weird, way_data is always 0 or invalid (red) during a simulation ...
<Fallenou>
in icache
<Fallenou>
I wonder if isim is capable of simulating the caches
<larsc>
does it toggle between 0 and red?
<Fallenou>
yes
<Fallenou>
10 clock cycles at 0, 10 at "red"
<Fallenou>
red meaning "x"
<Fallenou>
well not 10 but 12 to be exact
<Fallenou>
it's the same for way_tag
<larsc>
and read_data too?
<Fallenou>
oh, I think I have an idea, I have the net "refill_way_select" always at X
<Fallenou>
read_data ?
<Fallenou>
there is no wire read_data
<Fallenou>
the read_data of the "way data" ram is way_data
<Fallenou>
the read_data of the "way tag" ram is { way_tag, way_valid }
<larsc>
ah sorry, i was in dcache.v
<larsc>
but still way_data is driven by read_data of the way_data ram
<larsc>
and write_data is refill_data
<Fallenou>
I must say my associativity is at 1
<Fallenou>
so it's normal refill_way_select is at X
<Fallenou>
it's not used in the design
<Fallenou>
way_valid is never "X", funny
<Fallenou>
it should be driven by a blockram the same way as way_tag is :o
<Fallenou>
it comes from the same read_data output
<larsc>
that wouldn't be surprising if the blockram works fine, but the data that goes into it is already X
<Fallenou>
maybe it's because of enable which toggles a little bit
<Fallenou>
because of stall_a
<lekernel>
Fallenou: have you simulated it before your modifications?
<lekernel>
because I did it... and it works... I even got the BIOS prompt etc.
<lekernel>
(with the original soc ofc)
<Fallenou>
nop I haven't
<Fallenou>
but I didn't modify the icache
<Fallenou>
not a bit
<Fallenou>
but yes maybe I did something wrong in the top module
<lekernel>
though be careful when hotplugging the mini-b port - do not accidentally touch stuff that may cause short circuits
<dvdk>
well, trying hard not to cause a static discharge into the MM1 (which is just lying without housing on my table)
<lekernel>
best is to 1. connect the USB cable to the mini-b port 2. connect the JTAG pod to the M1 3. power on M1 and connect the other end of the USB cable
<dvdk>
uh, 3 steps. I'm really spoiled by plug&play.
<wpwrak>
dvdk: in the longer run, you may want to get rid of the cute angled cable and use a straight cable, with a hole in the sidewall
<larsc>
actually it's 4 steps ;)
<wpwrak>
dvdk: that way, you can close the M1 properly and don't have to worry about things falling into it
<wpwrak>
or even if you choose not to close it properly for quick access, the loosely placed plastic top can still cover everything
<wpwrak>
pity that there's probably no easy way to make the sidewall "configurable". well, we could make a replacement sidewall with a hole :)
<wpwrak>
wolfspraul: how's that for an accessory idea ? sell jtag board with replacement sidewall as an accessory. that way, it looks more significant :)
<dvdk>
wpwrak: can't close my MM1, as wolfspraul didn't give me any housing. it's just a bare board on a table.
<dvdk>
hmm, I only have a single /dev/ttyUSB0. according to the wiki there should be 2. what's wrong. linux (2.6.32) too old?
<wpwrak>
oh. having no case at all is nasty.
<wpwrak>
let's just hope your desk is more orderly than my junk pile :)
<wpwrak>
i think just /dev/ttyUSB0 is fine. i don't have anything else either. also 2.6.32 here.
<larsc>
dvdk: if there is only one, your linux is two new
<dvdk>
is the std flickernoise sw listening on the serial console? or do i need to boot it into some rescue mode/bios?
<wpwrak>
yeah, 115200 bps here too
<wpwrak>
yes, it listens
<dvdk>
hmm, trying to reboot the mm1
<dvdk>
ok, the mm1 software was frozen (did it freeze when I connected the usb cable?)
<dvdk>
(only have one monitor, can't see the mm1's output while typing here)
<dvdk>
nice, now I have an rtems shell :)
* dvdk
is cleaning up teh wiki page a little
<dvdk>
BTW another question about flashing:
<dvdk>
who defines the bitstream start addresses in the flash? is this a hardcoded property of the spartan6 chip?
<dvdk>
(just wondering what I have to do to install an alternate bitstream, like, say a bitcoin miner)
<larsc>
the standby bitstream is flashed at 0x0, isn't it?
<lekernel>
it's at 0 and then the standby bitstream gives another address
<dvdk>
uh, so you actually have a bootstrap process, whereby one FPGA design controls loading of another design?
<lekernel>
yes
<dvdk>
hopefully that's described in one of the many Xilinx pdf documents about the spartan6?
<lekernel>
yes, search for "spartan 6 multiboot"
<dvdk>
The "xc3sprog" tool mentioned in the wiki page, does that come with urjtag?
<lekernel>
but as far as I'm concerned... I'd prefer you work on the MM SoC which took me years to develop, rather than some stupid bitcoin miner
<lekernel>
we don't use xc3sprog, just urjtag
<dvdk>
lekernel: the bitcoin miner was just an example. but i'll need a step-by-step approach, synthesizing a two-liner that blinks the LED etc. currently the stack fpga+rtems+flickernoise is a little mind-boggling.
<wpwrak>
is accepted but produces the following code generation warning: Unit system: 7 internal tristates are replaced by logic (pull-up yes): ledm/ledc_reg<0>, ledm/l [...]
<wpwrak>
and of course, the result behaves strangely
<lekernel>
wpwrak: didn't I write something about synthesizer bugs regarding tristates ..?
<lekernel>
I don't remember if it was on the milkymist list or in some private emails
<wpwrak>
lekernel: so how do you work around them ? :)
<larsc>
one input signal, one output signal, one output enable signal and a tristate io buffer
<lekernel>
use an OE signal and then "assign pin = OE ? value : 1'bz"
<lekernel>
afaik the synthesizer always recognises this construct and maps it to a tristate buffer... if you wander away from it, you can encounter weird problems
<wpwrak>
larsc: how do i get such a tristate buffer ? all the examples i found just use 0/1/Z
<wpwrak>
hmm. promises to get suckish with OE ...
<wpwrak>
maybe i rather change the logic of the whole beast
<wpwrak>
git stash ... new try, new luck ...
<larsc>
wpwrak: what lekernal wrote
<wpwrak>
scary. implicit OE but with unreliable heuristics
<lekernel>
another problem migen would prevent you from running into btw :p
<wpwrak>
hmm. how ?
<lekernel>
no tristates :)
<wpwrak>
ha ha :)
<lekernel>
and only (OE, I, O) triplets can be converted to off-chip I/Os, using the bug-free synthesizer construct only
<lekernel>
there are no internal tristates in modern chips anyway
<wpwrak>
(triplets) okay, that's better
<lekernel>
Xst breaks down your construct using 'z into OE/I/O right at the I/O buffer
<lekernel>
sometimes it does it right, sometimes not
<wpwrak>
yeah :)
<wpwrak>
it's just puzzling that the logic falls apart quite so quickly
<wpwrak>
the semantics of my expression are still unambiguous
<lekernel>
you think so... but maybe there's some obscure gotcha of the verilog standard involved ;)
<lekernel>
or maybe it's a plain xst bug
<lekernel>
actually I do not want to know
<wpwrak>
i guess we'll never find out :)
<wpwrak>
;-)
<wpwrak>
funny. doens't even warn about 3'b0111.
<wpwrak>
i find the compiler's lack of interest in correctness a little disturbing ...
<larsc>
lekernel: can we rename .eq to .assign or something?
<wpwrak>
.be ? :)
<lekernel>
why? .eq is nice
<lekernel>
.be is very generic
<lekernel>
.assign is too much typing
<larsc>
if i read eq i always have to think of ==
<wpwrak>
"there be light". clear and concise :) i think people who dislike "be" don't think of it as an imperative
<wpwrak>
but yes, "eq" is bad
<wpwrak>
lekernel: maybe add a preprocessor with a nicer syntax ? :)
<wpwrak>
then use whatever python finds convenient to handle at the backend
<wpwrak>
that would also save you from having to go too deeply into bytecode introspection and such
<larsc>
but we want all the meta programming we get by using python
<lekernel>
.asg ?
<wpwrak>
you could still accept regular python syntax at the right places
<wpwrak>
ugly and uglier :)
<wpwrak>
.set ? .let ? heck, run sed 's/:=/.assign/g' :)
<wpwrak>
or maybe s/\.=/.assign/ :)
<larsc>
or use lambda functions and byte code analysis
<larsc>
;)
<lekernel>
unfortunately there's no good way to tell python to run a preprocessor on a module import
<lekernel>
so we'd have to use temporary files, which create a mess, and can go out of sync
<wpwrak>
you could write a wrapper than preprocesses the code and then call python
<wpwrak>
and you don't need temp files
<wpwrak>
unix has pipes :)
<lekernel>
but what if you have a module that contains some FHDL, and you import that module from another source file?
<larsc>
import files don't come through pipes
<wpwrak>
for pipes, see milkymist/tools/asm/pfpuasm.c:cpp it's pretty easy
<lekernel>
we'd have to modify python, write a PEP (which appears to be a lot of "paperwork"), get it rejected/rewritten a few times, finally get the patch merged, then wait for it to appear in distros, ... :)
<wpwrak>
;-))
<wpwrak>
i think i'll remain sceptical about the suitability python as a language for such things :) it was already hard for my TMC package and you're doing much more advanced things here
<lekernel>
what's the damn problem with it?
<lekernel>
commas and .eq ?
<lekernel>
that's about as far as it goes
<lekernel>
and those are problems that can be solved with a preprocessor, as you pointed
<wpwrak>
maybe also [x:y]. of course, this may be a case of having to choose between equally evil evils
<wpwrak>
yup. preprocessoes rule :)
<lekernel>
and the only problem with that preprocessor is that it needs a python modification to be done properly
<lekernel>
which brings in all the typical upstream problems, which are looking very bad for python
<wpwrak>
maybe a libc wrapper could do the trick
<lekernel>
hahaha :)
<wpwrak>
remap fopen, etc.,
<wpwrak>
it's been done before :)
<lekernel>
but then you need to set LD_PRELOAD every time you run python code that uses migen... not very friendly
<wpwrak>
well, you probably have a short shell script for that anyway, don't you ?