<ysionneau>
seems like Influxdb over UDP does not support timestamps in us or ms, but only in seconds
<ysionneau>
let's try the tcp/http protocole via aiohttp
GNUtoo-irssi has joined #m-labs
<GNUtoo-irssi>
Hi,
<GNUtoo-irssi>
I was wondering if it was possible to use a Spartran6 (used by many free software friendly boards, such as the milkymist, the novena, etc) with free software tools
<ysionneau>
you can use some free software tools, but you won't be able to "compile" verilog (or vhdl) down to bitstream (.bit/.bin file) with only free software tools
<ysionneau>
so far, I've only seen one open source tool generate working bitstream for Spartan 6, it's worlfgang spraul tool, and it "just" generates blinking led
<ysionneau>
wolfgang*
<GNUtoo-irssi>
ah ok, I though there was some attempt to reverse the bitstream format on mlab github page
<GNUtoo-irssi>
ysionneau: I know that, that's old...
<GNUtoo-irssi>
I was wondering about the presentation of Sebastien,
<GNUtoo-irssi>
it pointed to some git repositories on github
<GNUtoo-irssi>
it was about fixing such problem
<GNUtoo-irssi>
so I only saw the PDF, but it explained the complilation chain with the command line tools and the fact that the process is quite separated
<GNUtoo-irssi>
and that each piece can be implemented separately
<ysionneau>
18:32 < GNUtoo-irssi> ah ok, I though there was some attempt to reverse the bitstream format on mlab github page < this effort is the link I just gave
<GNUtoo-irssi>
telling that he has stopped due to time contraingt
<GNUtoo-irssi>
ahh ok
<GNUtoo-irssi>
let me find what I was talking about
<GNUtoo-irssi>
because the git address was not this one
<ysionneau>
maybe you are talking about yosys? which does not generate bitstreams afaik
<GNUtoo-irssi>
yes, I'm probably talking about uncomplete tools
<ysionneau>
ah yes, Sebastien (sb0 here) also started a reverse engineering effort
<ysionneau>
but AFAIK worlfgang went further in his RE work
<ysionneau>
wolfgang*
<GNUtoo-irssi>
ok
<GNUtoo-irssi>
So if I understand well, Wolfgang succedded to blink a led, while Sebastien's research did not produce concrete hardware related results but improved a lot the understanding of the bitstream format?
<ysionneau>
yes that's about it
<ysionneau>
Sebastien pointed wolfgang to information about the fpga internal architecture, which is in fact disclosed by the ISE tool
<GNUtoo-irssi>
If implemented in software, what exactly does Sebastien findings bring?
<GNUtoo-irssi>
Would that make FPGA usable with free software?
<ysionneau>
and then wolfgang implemented his stuff based on that and maybe some other papers
<whitequark>
as a bonus, you don't have to deal with the joke ISE people call "verilog compiler"
<ysionneau>
basically yosys synthetises, and I think it maps to FPGA resources, then you still need to implement a placer and a router, and then convert the design information into bitstream format
<GNUtoo-irssi>
thanks a lot
<ysionneau>
you can feed the output of yosys to proprietary tools also
<whitequark>
yeah, that's how you can use yosys for synthesis now. pretty much the only way
<whitequark>
ironically you can do ASICs with only FOSS tools
<ysionneau>
hehe
<GNUtoo-irssi>
lol
<GNUtoo-irssi>
Very ironic indeed
<GNUtoo-irssi>
What about CPLD and similar?
<ysionneau>
GNUtoo-irssi: you can do simulation though, without any proprietary tools
<ysionneau>
using icarus verilog, + gtkwave for visualization
<ysionneau>
(and Migen does interface with iverilog)
<GNUtoo-irssi>
yes, but I'm mostly interested in the practical stuff
<whitequark>
given enough money, ASICs are practical
<ysionneau>
given enough money, you can write a free software FPGA toolchain :)
<whitequark>
(well, a simulation is pretty much mandatory before using one anyway, and even for FPGAs)
<whitequark>
ysionneau: that's debatable
<ysionneau>
ah ?
<whitequark>
plenty of examples where more money meant worse software
<ysionneau>
well ok, same for anything
<whitequark>
for example, as i've mentioned above, the joke that ISE people call their verilog compiler
<GNUtoo-irssi>
Enough money probably means millions/Billions of Euros/Dollars
<ysionneau>
just stating that if you have money to invest, you can have some developers work on FPGA toolchain
<whitequark>
meh, no
<whitequark>
you need maybe four experienced engineers and a year
<GNUtoo-irssi>
ah ok
<whitequark>
wolfspraul worked on that for under a year, and it's sort of usable
<GNUtoo-irssi>
That's probably kickstartable then
<whitequark>
possibly
<ysionneau>
yes, but you would be talking to a very few experts then
<ysionneau>
crowd funding works well when you talk to a very large audience
<ysionneau>
but, I don't want to discourage you :)
<GNUtoo-irssi>
yes, indeed, here it's for the people wanting to directly use fpga
<GNUtoo-irssi>
I won't kickstart that myself, but I was thinking about insisting even more to get the "FPGA toolchain" inside the FSF high priority projects
<ysionneau>
good luck, FSF does not seem that much interested in hw stuff
<GNUtoo-irssi>
Personally I would find it very attracting to be able to benefit from such thing
<ysionneau>
maybe FSFe
<GNUtoo-irssi>
Well, for them it's "software", and it's important
<GNUtoo-irssi>
The novena has an FPGA.
<GNUtoo-irssi>
And they would not be able to recommend it because of the FPGA
<whitequark>
has anything at all ever emerged out of FSF's high priority project list?
<GNUtoo-irssi>
well, few things indeed
<GNUtoo-irssi>
sometimes the projects got a boost thanks to that
<whitequark>
what even happened to libredwg?
<GNUtoo-irssi>
And my point of view is just that it gave a boost to such projects
<GNUtoo-irssi>
that's all
<GNUtoo-irssi>
it doesn't magically make things happen
<whitequark>
I don't see a point in even bothering about that
<GNUtoo-irssi>
Because that is all I could do
<GNUtoo-irssi>
While I find FPGA so exiting, I've not the required knowledge to even write a program in VHDL, but verilog seem very close to sequencial programming
<kristianpaul>
the FPGA is just hardware, they cant just blame it for been as it is
<ysionneau>
What is Novena doing with the FPGA?
<kristianpaul>
Glue logic if remenber well
<larsc>
verilog and vhdl a basically the same
<GNUtoo-irssi>
Well, for now few things: SDR, analyzing protocols, osciloscope/logic analyzer
<kristianpaul>
and some digital analizer stuff as well
<GNUtoo-irssi>
But the potential is just enormous
<ysionneau>
not bad
<ysionneau>
but I think there are tons of boards you can find with FPGA+cpu, you can even find boards with FPGA containing a CPU (Zynq)
<GNUtoo-irssi>
Like you need another 1000 NIC => make flash
<ysionneau>
what does those products give you? Freedom? I don't think so
<kristianpaul>
FSF as always ignore the bootrom present on many computers
<GNUtoo-irssi>
The other use I see is for coreboot bringup: You then make hardware that doesn't require RAM to be inited
<ysionneau>
not more than any laptop runing Linux/BSD
<ysionneau>
apart maybe from the schematic of the board ...
<GNUtoo-irssi>
well, the core idea is that hardware is not modifiable while software is
<GNUtoo-irssi>
(that's their point of view)
<GNUtoo-irssi>
so as soon as the hardware can be modified not by making a new one
<GNUtoo-irssi>
then they treat it as software
<GNUtoo-irssi>
so they threat the FPGA bitstream like software
<ysionneau>
well, if you had open source fpga toolchain, or cheap ASIC process, or open source FPGA (+toolchain) that could be interesting to have a computer like this
<kristianpaul>
They are just keep narrowing this just to software
<GNUtoo-irssi>
and a bootrom burned in a SOC as hardware
<GNUtoo-irssi>
Well, they had to draw a line somewhere
<GNUtoo-irssi>
So I am very aware that this line is far from beeing perfect
<GNUtoo-irssi>
I've a good example to prove that
<ysionneau>
I would rather have a laptop running Linux on FPGA with multi-core OpenRISC, on some "open source" FPGA board
<ysionneau>
than buying a Novena I think
<ysionneau>
Novena does not bring me open source liberties
<GNUtoo-irssi>
It potentially bring 100% free software but has the FPGA issue.
<ysionneau>
well, it runs on a CPU that I don't know
<ysionneau>
you don't know what's inside
<GNUtoo-irssi>
Some coreboot laptops also brings 100% free software but has the embedded controller issue.
<whitequark>
not 100%
<whitequark>
still has proprietary video blob
<GNUtoo-irssi>
so that's about it, it doesn't go furthurer
<GNUtoo-irssi>
yes, that's why I said potentially
<GNUtoo-irssi>
there is still some work to be done
<GitHub196>
[artiq] sbourdeauducq pushed 4 new commits to master: http://git.io/prYn
<GitHub196>
artiq/master 4ba54ac Sebastien Bourdeauducq: test: do not close/recreate the asyncio event loop (WA for asyncio bugs when multiple tests are run)
<GNUtoo-irssi>
Porting a 100% free general purpose distro to it is one,
sb0 has joined #m-labs
<GNUtoo-irssi>
then remains making some hardware work well, like the VPU, the 3d accelerator and so on
<GNUtoo-irssi>
I'm unsure about the exact status of theses
<GNUtoo-irssi>
So on the freedom point of view, it's worse than a libreboot computer right now
<GNUtoo-irssi>
But the hardware still is attractive: ARM CPU, battery controller for any RC battery you wish, hackable
<ysionneau>
sb0: is it normal that when I run the Flopping F simulation, I get nothing in the Scheduler window? nothing in Queue or Timed Schedule ?
<ysionneau>
but I can see the RID completed successfully in console
<sb0>
ysionneau, no. but it works for me, and worked as well on the oxford computer.
<ysionneau>
ok
<sb0>
ysionneau, do you have the problem as well with the command line client, or is it only in the GUI?
<sb0>
ysionneau, I guess you can fire-and-forget asyncio tasks that do one influxdb request. just make sure they don't stay in memory forever...
<ysionneau>
yep with aiohttp for instance I can put a timeout on the request
<sb0>
that will make the task terminate, but what I was saying is it might linger in memory after termination for some reason (and asyncio has tons of quirks, if not bugs). so have a look at that...
<sb0>
GNUtoo-irssi, verilog = vhdl with a different syntax.
<sb0>
and a more lax type system
<ysionneau>
sb0: if I submit the experiment using artiq_client and visualize queue with artiq_client show queue, then yes I can see the experiment in the queue
<ysionneau>
hummm
<ysionneau>
but then the queue goes empty and stays that way, even if I submit more experiments
<ysionneau>
so there is something wrong on my side :o
<ysionneau>
ah no sorry it seems to work, but I need to interrupt/relaunch the artiq_client show queue to update it
<sb0>
that shouldn't happen
<sb0>
artiq_client is supposed to update stuff in real time
<sb0>
well, debug it then :)
<ysionneau>
yep let's see what's wrong :)
<sb0>
you can probably wireshark the sync_struct connection and see if the master sends the updates correctly
<ysionneau>
ok, that was some local changes that I forgot to stash...
<sb0>
also, we need a unit test for sync_struct.
sb0 has quit [Quit: Leaving]
<GitHub12>
[artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/poyj
<ysionneau>
hum weird, if I say to influxdb I want to use time_precision="u" (microseconds) and I send time=1426108604298315 (seen in wireshark) then the web frontend of influxdb only shows me a time of 1426108604298 (so skipping last 3 digits)
<rjo>
ysionneau: we are unlikely to need sub-second precision for the timestamps now. if the rate is higher than a second, you are generating probably generating too much data. and that (influxdb) interface will change anyway afaict.
<rjo>
sb0: what is your usecase for binding to an explicit list of ip addresses?
<ysionneau>
rjo: ok :)
<rjo>
are you targeting influxdb 0.8 or 0.9rcX?
<sb0>
rjo, listening to localhost (for responding to pings and termination requests from the controller manager) plus another interface
<ysionneau>
here I have 0.8.8 influxdb running
<sb0>
rjo, since there is close to zero protocol security, I don't really like binding on any interface
<rjo>
firewalls are mandatory already.
<rjo>
here at least.
<rjo>
and a firewall is how i would enforce access restriction to first order.
<rjo>
ysionneau: ack. there quite a few changes in 0.9 but i don't think the client api side will be extremely different. you might want to have a quick look at 0.9 anyway to check that they are not diverging too much.
<sb0>
rjo, yes, it's not critical. but since the "python modified on my machine -> python installed by distribution" path likely takes forever, better submit that early.
<ysionneau>
rjo: anyway I'm using tcp rest api so it should not have changed
<ysionneau>
(with aiohttp)
<ysionneau>
sb0: I guess you thought about this, but once you've got influxdb set up, you can have very nice visualization with http://grafana.org/
<ysionneau>
you can build a dashboard showing query results, where you can zoom in/out
<sb0>
yes, I think that was the main point of using influxdb *g*
<ysionneau>
hehe
sb0 has quit [Quit: Leaving]
<rjo>
ysionneau: you might not be aware. i have been using influxdb and grafana for almost a year now to do these things for all kinds of data from the lab and my ion traps.
<ysionneau>
ok I didn't know, but it seems pretty appealing indeed!