<wolfspraul>
wpwrak: about c-to-verilog, one side-effect of my current fpgatools work is that if I get it to work, at first you will only be able to program the chip with C
<wolfspraul>
that's more born out of not having a verilog/iverilog/edif compiler though
<wolfspraul>
so there will be a c library with hopefully a bit more high-level function set, and you use that to fill the fpga resources with a design
<wolfspraul>
I will stay at that level until I have a decent subset of the fpga features working, which will take a while
<wolfspraul>
that way I can save any verilog/edif detour now
rejon has joined #milkymist
<wpwrak>
wolfspraul: sounds like an interesting order of things ;-) C before verilog
qi-bot has joined #milkymist
<wolfspraul>
well, I'm a beginner
<wolfspraul>
but as such, I don't currently understand that high vertical stack
<wolfspraul>
from where I am now, the physical resources, if I look up, there's first the place and route stage
<wolfspraul>
above that, logic mapping
<wolfspraul>
above that, logic optimization
<wolfspraul>
above that, the verilog compiler
<wolfspraul>
and above that, things like c-to-verilog or migen
<wolfspraul>
wow
<wolfspraul>
and when the stack is somehow not powerful enough, you add more stuff to the top of it, more abstractions?
<wolfspraul>
well then, what I work on is more like a 'libfpga' for now
<wolfspraul>
that will allow you to write into the fpga resources, and if the api is done well it should not be too inefficient to use this api to load a design into the chip
<wolfspraul>
I will not work on connecting the traditional vertical stack to this until at least an important subset of the fpga's features work
<wolfspraul>
and then I will probably start in iverilog, reactivate the fpga targets there
rejon has quit [Ping timeout: 246 seconds]
<wpwrak>
i think by the time you get there, you'll have a much clearer picture of what you need anyway
<wolfspraul>
I currently think one reason for the high stack is that the lower levels are closed
<wpwrak>
also, once you bring your baby into the open, there ought to be some folks who are interested to help. there are a lot of cute algorithms waiting for a problem they can solve :)
<wpwrak>
that may very well be the case
<wolfspraul>
I'm curious about the vivado thing, whether there is anything fundamentally new in there, or just more layers on top, with gcc/linux/arm integration etc.
<wpwrak>
for making a "compiler", the best approach is probably to make something that can build a complete skeleton, no matter how inefficiently. then add manual overrides that guide it.
<wolfspraul>
so is vivado a repackaged ise + new things on top? or a from-scratch reimplementation of fundamental tools in the process?
<wolfspraul>
I don't know
<wolfspraul>
yeah I'm not worried about that, I really focus on the bit level and fpga physical resources
<wpwrak>
with the whole thing open, you can collapse the stack at your leisure
<wolfspraul>
yes, that's for later
<wolfspraul>
now I work in switches, I think there are pass transistors, tri-state buffers, and multiplexers
<wolfspraul>
hopefully that's it
<wpwrak>
already whether to c-to-verilog or to c-to-netlist or maybe even c-to-bitstream would be entirely your/our choice
<wolfspraul>
sure just explaining my thinking, since I was torn over these things
<wolfspraul>
such as whether I should look at iverilog and restart the fpga target there
<wolfspraul>
but I don't need it, it's a detour that won't help me
<wpwrak>
yeah, there are only so many things a switch can do :)
<wolfspraul>
who knows :-)
<wpwrak>
at the beginning, you want something very simple anyway. doesn't matter how inconvenient it is.
<wolfspraul>
it's not inconvenient
<wolfspraul>
just if you build bottom up, the need for a high vertical stack is not immediately obvious
<wolfspraul>
that will come later when dealing with much larger designs
<wpwrak>
x = create_lut(NOR); route(x.out, y.in, sw1, sw2, ...); etc. :)
<wolfspraul>
yes
<wolfspraul>
something like that
<wpwrak>
well, make that create_lut(NOR, LUT_number); :)
<wolfspraul>
and you can build the api up a little
<wolfspraul>
create_bunch_of_luts()
<wpwrak>
that's already very very sophisticated :)
<wpwrak>
but i wouldn't worry about the tall stack. chances are others will write most of that for you, if you let them :)
mumptai has quit [Ping timeout: 246 seconds]
voidcoder has quit [Read error: Connection reset by peer]
Fallenou has quit [Ping timeout: 260 seconds]
Scopeuk has quit [Ping timeout: 260 seconds]
cxadams has quit [Ping timeout: 260 seconds]
Fallenou has joined #milkymist
Scopeuk has joined #milkymist
cxadams has joined #milkymist
voidcoder has joined #milkymist
<lekernel>
what c-to-verilog does is generate a hardware implementation of a normal algorithm written in C
<lekernel>
not manipulate the fpga/verilog level from C routines
kristianpaul has quit [Read error: Connection reset by peer]
voidcoder has quit [Read error: Connection reset by peer]
voidcoder has joined #milkymist
kilae has joined #milkymist
<wolfspraul>
yes I looked at jbits
<wolfspraul>
nothing in it like all other similar projects, the closest is debit but even that is basically nothing
<wolfspraul>
the jbits guys made their fatal mistake right on day 1 when building on top of the closed & proprietary xilinx library, no? was it that one? I studied so many I lost overview a little, but I think that was that one
<wolfspraul>
then in the end xilinx pulled the plug under their library and that was the end of jbits, obviously
<wolfspraul>
if that was another one, sorry, then I confused them. won't look at it again now...
<wolfspraul>
debit at least seems to have a nice crc algorithm I may end up reusing :-)
<wolfspraul>
not that that is in any way central to the problem though
<wpwrak>
(studied so many) you really should take notes. this sort of background research is important when you have to position/defend your work.
<wolfspraul>
yes sure but I really want to get something working first
<wolfspraul>
the majority of prior attempts in this area either gives up right away, or ends with large databases of whatever structured fpga data, and that was it. data overload, bridge collapsed...
<wolfspraul>
my stuff may very well end like that too, and then there is no need to even document that
<wolfspraul>
today is switch day :-)
<wolfspraul>
and tomorrow too, unfortunately. surely. and all of next week :-)
<wpwrak>
yeah, but by then you'll have forgotten the details of your background research (see above) and you'd have to do it again, which you'll find countless excuses for not doing, which in turn will make you miss opportunities to properly present your project.
<wpwrak>
always keep in mind that you may get approached by people who'd be willing to spend not only praise but also money :)
<wolfspraul>
also in the case of jbits, that's long long dead and history
<wpwrak>
(switch week) well, i've had worse ;-)
<wolfspraul>
I do plan to contact the recobus guys in germany, but only if I actually have something I think is worthy of their attention
<wolfspraul>
the recobus team/effort is the most active and most advanced currently, that I'm aware of
<wolfspraul>
they clearly are ahead of where I am, reading their papers etc. but unfortunately it's all closed, except for some binary apps they are releasing
<wolfspraul>
at least if I go back to their papers every few weeks, it slowly makes more and more sense
<wolfspraul>
so I must be on the right track :-)
<wolfspraul>
trust me werner it's too early to make a big show now
<wolfspraul>
I have nothing, just falling around
<wolfspraul>
and that after 2 months
<wolfspraul>
so let's see
<wolfspraul>
I think I will go back to the bits proper soon, after the whole modeling detour
<wolfspraul>
bits is more fun than model
<wpwrak>
i'm not talking about a big show before you have something to show. that would obviously be ill-advised. but you should make sure what you learn isn't lost. and background research is an important part of that.
<wpwrak>
and 2 months is nothing ;-)
voidcoder has quit [Remote host closed the connection]
kyak has quit [Ping timeout: 264 seconds]
voidcoder has joined #milkymist
<lekernel>
jbits is a xilinx project, no?
<lekernel>
and as far as I know, it works. if you have old virtex-2's :)
<lekernel>
that is, you can configure LUTs, route stuff, etc. and generate a programmable bitstream in the end
kristianpaul has joined #milkymist
kristianpaul has quit [Changing host]
kristianpaul has joined #milkymist
kyak has joined #milkymist
<wolfspraul>
the famous 'it works'
<wolfspraul>
how does this help us?
<wolfspraul>
1. it's abandoned for >10 yr
<wolfspraul>
2. it's based on a closed library which is officially 'retracted' and what not for ages
<wolfspraul>
3. it only "works" with ancient fpgas, where I'm sure not many people have tried this "working" status in years
<wolfspraul>
4. there is no interesting documentation whatsoever in it or around it that we could learn anything from
<wolfspraul>
so what is it good for then? I don't get it
<wolfspraul>
it's merely a distraction. the less brain resources we waste on it the better.
<wolfspraul>
I can recommend that fpga book you recommended to me a while back
<wolfspraul>
that's a nice one
<wolfspraul>
and then the recobus project, they have good work and good papers
<wolfspraul>
then there are some interesting bits in debit, unfortunately they stopped way too early though, imho
<wolfspraul>
after those the quality and reusability drops a lot
<wolfspraul>
sure there are some more, like this jbits, or tarc? something with tar...
<wolfspraul>
and a few others
<wolfspraul>
but the quality lacks there, a lot
<wolfspraul>
and some are really lousy, more like 5 page wishful thinking thesis...
<wolfspraul>
the bottom end
rejon has joined #milkymist
<lekernel>
your program seems to aim at the same API as jbits in the end
<lekernel>
which is different from c-to-verilog or logic synthesis
kristianpaul has quit [Ping timeout: 248 seconds]
<wolfspraul>
yes
<wolfspraul>
lowest level first
<lekernel>
don't know why you say there's "nothing it in". it does what your program is supposed to do, only the source is closed
<lekernel>
in it
<wolfspraul>
ah, yes :-)
kristianpaul has joined #milkymist
kristianpaul has joined #milkymist
kristianpaul has quit [Changing host]
kristianpaul has quit [Ping timeout: 272 seconds]
kyak has quit [Ping timeout: 246 seconds]
voidcoder has quit [Read error: Connection reset by peer]
voidcoder has joined #milkymist
kyak has joined #milkymist
kyak has joined #milkymist
kyak_ has joined #milkymist
kyak has quit [Read error: Connection reset by peer]
rejon has quit [Ping timeout: 272 seconds]
fpgaminer has quit [Remote host closed the connection]
fpgaminer has joined #milkymist
rejon has joined #milkymist
kristianpaul has joined #milkymist
kristianpaul has joined #milkymist
kristianpaul has quit [Changing host]
kristianpaul has quit [Read error: Connection reset by peer]