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
fengling has joined #m-labs
_rht has quit []
<whitequark>
btw, when the board is not responding, it is not completely powe roff
<whitequark>
the LCD is still on and displays one row of blocks
<whitequark>
some LEDs are on too, but the fan is not spinning
<whitequark>
it seems that the connector doesn't just disconnect everything but rather undervolts the board
<sb0>
yes, you can also hear the fan speed change when you touch the connector
<sb0>
and still in the department of crappy components, the power switch is shorted on
<sb0>
and I've seen both those problems on other boards.
<sb0>
I wonder if we should bother replacing that power connector (requires ordering the correct one, and then unsolder the broken one which uses large, plated-through holes that can be a pain)
<sb0>
or just cut the power cord and solder it on the PCB
<sb0>
well I guess the broken one shouldn't be too painful to unsolder: we can cut it and then pull the pins one by pne
<sb0>
I'm not sure if the connector on the power supply or on the board is faulty though
<sb0>
wtf, it's a molex part? I didn't know they made broken crap like that
<whitequark>
sb0: I can desolder that connector very easily using that SMD rework low melting temp solder
<whitequark>
I forgot how it's called for a moment
<whitequark>
that's the same way I reworked my laptop's connector without hot air and its risks
<sb0>
ok. but maybe it's the cable side anyway.
<whitequark>
I do think it's the cable side.
<whitequark>
there is basically nothing to break board side.
<sb0>
whitequark, there should be a kc705 box behind the fridge
<sb0>
with an adapter to put the kc705 in a PC (a silly thing to do, as this crap will fry your motherboard)
<sb0>
you can take it apart and solder it to the power supply
<whitequark>
ok, I will do that once I'm in the lab
<sb0>
that other connector might be broken as well though
<sb0>
our kc705 isn't the only one I've seen with power problems ...
evilspirit has joined #m-labs
<sb0>
ysionneau, why do you call flush() after opening the serial port?
<sb0>
the pyserial doc says: "wait until all data is written". there was nothing written.
rohitksingh has joined #m-labs
<sb0>
ysionneau, and why did you define _Tcube.send(), and sometimes use it, and sometimes do Message(...).send(self.port)?
<sb0>
it's not even symmetric, i.e. there is no self.recv function ...
<sb0>
this code is very sloppy
mumptai has joined #m-labs
<whitequark>
sb0: the connector seems alright
<whitequark>
the fan doesn't change speed when I touch it
<sb0>
ysionneau, status_report_counter is only used in the subclass Tdc, therefore it should be initialized there, not in the parent class ...
<sb0>
were you too lazy to overload __init__ or what
<sb0>
ysionneau, why is there a move_stop function, when every other function is supposed to wait for completion?
<sb0>
ditto is_moving
rohitksingh has quit [Quit: Leaving.]
_rht has joined #m-labs
_rht has quit [Client Quit]
fengling has quit [Quit: WeeChat 1.4]
evilspirit has quit [Read error: Connection reset by peer]
<FabM>
Hi, I've got a problem with quartus synthesis and Interface() object parameters
<FabM>
If I declare an Int parameters in Migen like it : Instance("altera_pll", p_duty_cycle0=50, ...)
<FabM>
Migen will generate verilog parameters like it : .duty_cycle0(6'd50), ...
<FabM>
And value 6'd50 raise an error in Quartus synthesizer : Parameter "duty_cycle" of instance "general[0].gpll" has illegal value "110010"
<FabM>
I managed to fix the error with top.v code following modification :
<FabM>
.duty_cycle0(50), ...
<FabM>
Is there an option in Migen to tell it not generating integer constant with size'dvalue, and just keep int value ?
<FabM>
In fact I found the solution -> simply adding quote arround the integer parameter -> "50"
evilspirit has joined #m-labs
bgouraud has joined #m-labs
<GitHub81>
[artiq] sbourdeauducq pushed 5 new commits to master: https://git.io/vaHDl
<sb0>
yes, so you're basically giving it a string value
<FabM>
yes
<sb0>
the acceptance of a string value where an integer is expected is an altera idiosyncrasy
<sb0>
especially if an integer of another bit width doesn't work ...
<sb0>
try Constant(50, 32)
<sb0>
or Instance.PreformattedParam("50")
<FabM>
Ok I try it
<rjo>
PreformattedParam should be in the docs.
<FabM>
Constant(50, 32) does'nt works : Error (14024): Parameter "duty_cycle" of instance "general[43].gpll" has illegal value "00000000000000000000000000110010" assigned to it. Possible parameter values are 1 to 99, inclusive. File: /opt/quartus/altera/15.1/quartus/libraries/megafunctions/altera_pll.v Line: 749
<rjo>
i would guess that the bitwidth is not the problem here. altera docs don't even say what it is
<sb0>
but verilog does. the default bit width of an integer constant is 32.
<FabM>
It's ok with Instance.PreformattedParam("50")
<rjo>
then probably altera only understands strings or literals.
<rjo>
bitwidth-less literals
<FabM>
But the verilog is generated with quotes "50" ...
<FabM>
No
<FabM>
In fact is generated without quote sorry
<FabM>
Ok I'll change my platform code with Instance.PreformattedParam("50") then.
<larsc>
if it is without any prefix it is a integer constant, isn't it?
<larsc>
110010 > 99
<sb0>
Instance.PreformattedParam("50") should generate a verilog without quotes