<viric>
hey the USRP gnu radio is super expensive :)
<kristianpaul>
yes , but i plan get one any time next year i hope
<kristianpaul>
is relly usefull for debugging
<kristianpaul>
rellay*
<viric>
it looks very ogod
<viric>
good
<viric>
a radio laboratory should have one
<kristianpaul>
viric: less espensive that buying separate radio stuff
<viric>
I agre
<viric>
e
<kristianpaul>
also you add it a ITX board and you're done
<kristianpaul>
i saw openBTS shop and they sell it with on, is good idea
<viric>
can it do CDMA?
<kristianpaul>
i dont know
<viric>
kristianpaul: how you test the speed on the minipc for the gps code'
<kristianpaul>
correlation time, but first i need pass the simd-like self test  :)
<viric>
kristianpaul: cómo lo pruebas?
<viric>
can't you test it without simd?
<kristianpaul>
hehe , no i think , simd is heart for acquisition step
<viric>
does the loongson2f have simd instructions for floating point?
<viric>
or your calculations don't involve floating point?
<kristianpaul>
i dont know yet, i need read manual first
<kristianpaul>
float point dont know either, is just FFT from data-like -1,0,1
<viric>
for what I read...
<viric>
it only has integer SIMD instructions
<viric>
so, they can work as fixed point.
<kristianpaul>
damn mocp dint fit on nanonote screen :/
<wpwrak_>
kristianpaul: (simd) you mean the correlation ?
<kristianpaul>
nope
<kristianpaul>
MMX like instructions
<wpwrak_>
kristianpaul: yes, but for what kind of operation ?
<kristianpaul>
wpwrak_: fft
<wpwrak_>
ah yes, fft should be happier with that
<viric>
are you using fftw3?
<kristianpaul>
i will for first test, but i want to try re-use gps-sdr code later
<qi-bot>
[commit] Cristian Paul Peñaranda Rojas: Sync signal to mcu is taken from SiGE as result removed non needed code and fixed identation http://qi-hw.com/p/ben-gps-sdr/f7203fa
<qi-bot>
[commit] Cristian Paul Peñaranda Rojas: Updated makefile to be more friendly and removed non required features http://qi-hw.com/p/ben-gps-sdr/4e57bf8
<kristianpaul>
he
<kristianpaul>
something really weird happen after load bistream to fpga, screen just got crazy :/ and i lost ssh conection
<lekernel>
on sie?
<kristianpaul>
yes
<kristianpaul>
hmm is my bitstream
<kristianpaul>
what's wrong with port A :/
<kristianpaul>
In theory i just send a 4bits data plus a clock signal at 2.048Mhz
<Madridman>
hi
<Madridman>
please anybody could recommend the best book to learn about gpu's? basics
<Madridman>
I would like to learn the typical GPU's architectures, theorical things
<Madridman>
not interested in programming GL and such
<Madridman>
everybody's sleeping?
<viric>
are you more interested in the power supply and clock of the GPU?
<lekernel>
Madridman: if you're interested in how GPUs are made, have a look at my thesis (on milkymist), and specifically the chapter on the texture mapping unit (tmu)
<lekernel>
the tmu implements several fundamental features of GPUs
<lekernel>
but if you have no prior experience with opengl, I'd recommend playing around a bit with it for starters
<lekernel>
it will really help you understand what is going on
<Madridman>
lekernel I would like to check your thesis, where is milymist?
<Madridman>
not interested in opengl, just electronic architecture theorics
<lekernel>
milkymist.org
<Madridman>
i do not pretend to program
<lekernel>
well, opengl understanding will really come handy
<lekernel>
and opengl is already pretty low-level itself
<Madridman>
sure but before it could be good to know how the memory etc. are placed
<Madridman>
all the buses and rest of components
<viric>
lekernel: is the milkymist source available?
<lekernel>
yes, of course
<viric>
(to me, I mean, for example :)
<Madridman>
I know plastation and xbox have nothing to do one each other
<viric>
lekernel: is it in vhdl?
<lekernel>
no, verilog
<viric>
ouch. Bad luck I had. :)
<lekernel>
verilog is little more than a less verbose vhdl, so if you already know VHDL well enough you'll have little trouble with verilog
<Madridman>
lekernel sorry, I accessed the web page http://milkymist.org/ but I don't know where is the theorical part of your thesis
<Madridman>
lekernel that fpga can compete with a commercial architecture?
<Madridman>
I mean is slower?
<lekernel>
having seen a demo of ARM Mali on a FPGA, I think it does :)
<lekernel>
at least performance-wise
<lekernel>
but it lacks some features (that I didn't need for my application) to make a complete GPU that supports all OpenGL application
<viric>
lekernel: do you use any floating point there?
<Madridman>
a fpga can be as fast as a commercial video card as ati or nvidia?
<lekernel>
the texturing unit is fixed point, but the pfpu (roughly, a vertex shader) uses 32-bit ieee 754
<lekernel>
floating point
<lekernel>
Madridman: generally no
<lekernel>
at least for GPU operations
<Madridman>
so fpga's are not as useful as they say
<Madridman>
they has limitations
<Madridman>
(it)
<lekernel>
everything has limitations
<lekernel>
the fpga is however a lot more flexible than a gpu
<Madridman>
ok, do you know a book or web or resource which speaks about fpga's so I could know better them?
<viric>
lekernel: aren't Floating Point operations taking lots of logic in the fpga?
<Madridman>
just general theory
<lekernel>
so if your particular application doesn't map nicely to, say, CUDA code, the FPGA can still deliver there
<lekernel>
viric: no, I'm not using the Opencores FPU ;)
<viric>
lekernel: where did you get the FPU operations from then?
<lekernel>
I wrote some code...
<viric>
ah
<Madridman>
lekernel do you know a book or web or resource which speaks about fpga's so I could learn and know better them?
<lekernel>
it's not 100% IEEE 754 compliant btw
<viric>
ahh.
<lekernel>
the number format and a lot of things are the same
<viric>
Madridman: get a manual from an FPGA seller
<lekernel>
but I don't totally respect details of the standard such as the way of rounding numbers
<viric>
Madridman: get the manual for the spartan3 fpga for example.
<lekernel>
or how to deal with numbers like NaN or infinites
<Madridman>
viric but I want to know the general common basics, not a concrete seller
<lekernel>
again - I don't need those for graphics processing
<viric>
clear.
<Madridman>
Eg. which kind of transistors or biestables are used generically, etc
<viric>
Madridman: that thing you call "generic fpga" does not exist. There are only concrete FPGAs :)
<Madridman>
ok, imagine I'm new (what is absolutelly true), I never heard about a thing called FPGA. You can't give a manual of a concrete implementation because I don't know even what technology we are speaking about
<viric>
Madridman: look for the "Spartan 3 User Guide"
<viric>
Madridman: I call FPGA a chip that can be programmed *by software* to mimic a logic circuit. Software allows you to rearrange whatever is there inside to get as if you had made a circuit concerning whatever FPGA pins you want.
<Madridman>
ok, but later what you get is a physical circuit isn't it?
<Madridman>
i mean, logical gates interconnected
<viric>
yes.
<Madridman>
ok, that pdf's seems to have theorical information too, that's what I need for starters
<viric>
The circuits there come at some limitations, of maximum clock frequency, maximum number of clock signals, maximum number of flip flops...
<viric>
the more you pay, higher the limits
<Madridman>
I understand
<Madridman>
the scenes draft looks nice
<viric>
there are hardware description languages, and most FPGA sellers offer 'compilers' for those common languages to whatever their FPGA needs.
<Madridman>
yes, as vhdl which I hates
<viric>
So you can describe your circuit in a common way, and expect it to work among different FPGA vendors.
<viric>
Madridman: there is also verilog
<Madridman>
for sure is much better
<viric>
no idea.
<viric>
and how you have such an opinion about that? Some minutes ago you did not know anything about FPGA
<Madridman>
sure
<Madridman>
that's because I need theorical resources, to avoid bugging you
<Madridman>
is reallistic to pretend have a fpga's hardware which competes against commercial circuits (performance, fabrication costs)?
<viric>
no
<Madridman>
so it'sr just experimental things oriented?
<lekernel>
by "commercial circuit", you mean full customs ICs?
<Madridman>
well, a microprocessor yes
<viric>
FPGAs can compete only in the sense that they can be 'reprogrammed'
<lekernel>
in a typical design 90% of the FPGA transistors are wasted
<viric>
lekernel: hey, talk for your designs
<viric>
;)
<Madridman>
my university research for multiexecution architectures specific for some tasks, so there are just experiments
<lekernel>
but if you compare that to the NRE of spinning an ASIC, sometimes it makes economic sense to keep an FPGA in a product where the FPGA design remains static
<viric>
FPGA over ASICs may have advantages on a) reprogrammability and b) cheaper for small productions