Topic for #homecmos is now Homebrew CMOS and MEMS foundry design | http://code.google.com/p/homecmos/ | Logs: http://en.qi-hardware.com/homecmos-logs/
soul-d has quit [Remote host closed the connection]
wolfspra1l has joined #homecmos
wolfspraul has quit [Ping timeout: 248 seconds]
<azonenberg> Saw it already
<azonenberg> Looks interesting
<wolfspra1l> azonenberg: I'm looking a bit into hls (high-level synthesis) now
<wolfspra1l> panda, shang, legup, c-to-verilog, fpgac, etc.
<azonenberg> cool
<wolfspra1l> do you know much about that?
<azonenberg> No
<wolfspra1l> I am wondering whether I should work on a llvm-backend for fpgatools
<azonenberg> You might want to look at xc2c* at some point
<wolfspra1l> what is that?
<azonenberg> coolrunner-ii CPLDs
<azonenberg> the bitstream for the smallest device is only ~12kbits
<azonenberg> programming files are ASCII and even include comments
<azonenberg> for which bits go to which function block etc
<wolfspra1l> I don't know anything about those chips
<wolfspra1l> why would I want to look at them?
<azonenberg> they're CPLDs so the microarchitecture is totally different from FPGAs
<azonenberg> but they're dirt cheap (like a dollar a pop)
<azonenberg> and very simple
<azonenberg> a full toolchain would likely take a lot less time than something like xc6s
<azonenberg> But the downside is that since the uarch is so different from fpgas not much would port
<wolfspra1l> why would I want to look at them?
<azonenberg> Because they're probably the easiest programmable logic in current production to make a full FOSS toolchain for
<wolfspra1l> I know nothing about those chips so maybe it's good to learn, but I wouldn't know why right now
<azonenberg> not useful for much more than glue logic etc, of course
<azonenberg> few hundred to few thousand gate equivalents
<wolfspra1l> then you go and try :-)
<wolfspra1l> what I see in xc6 so far is all very easy
<azonenberg> there's a reason i mentioned you should look ;)
<wolfspra1l> but what is better about those chips than say xc6slx9 ?
<azonenberg> i'm looking into them in more depth though
<wolfspra1l> my current toy
<azonenberg> Oh, xc6s would be much better to have a full toolchain for in the long term
<wolfspra1l> put the 'ease to write foss toolchain' aside for a moment
<wolfspra1l> ah ok
<wolfspra1l> then I shall continue there :-)
<azonenberg> but i think as a short-term goal if you want a FOSS programmable logic toolchain for ANYTHING
<azonenberg> those would be the quickest route
<wolfspra1l> has someone tried?
<azonenberg> Not to my knowledge
<azonenberg> I might look at that since there would be little overlap with fpgatools
<azonenberg> the microarchitecture has basically nothign in common
<azonenberg> but it's extremely simple
<wolfspra1l> sure
<azonenberg> just a bunch of muxes and sum-of-products arrays
<wolfspra1l> I like to first understand the quality of the chip (the hw)
<wolfspra1l> let's assume all sw can be written
<azonenberg> Yeah
<azonenberg> Thats the thing that makes these attractive targets for study - simplicity
<azonenberg> a couple of global clocks and stuff
<wolfspra1l> if by that comparison there is nothing or not much interesting left in xc2c*, then I'm probably not interested
<azonenberg> IOBs
<azonenberg> then just logic
<azonenberg> no multipliers, no ram, no SERDES, no memory controller
<wolfspra1l> again: I have done a lot of work on xc6 in the last months
<azonenberg> Yeah
<wolfspra1l> and I tell you: it's all easy
<azonenberg> Given where you are, you should keep going
<azonenberg> i'll look at xc2c over the winter break if i have time
<wolfspra1l> I will have the blinking led finished this coming week
<azonenberg> :D
<wolfspra1l> then a counter with bscan-accessible register
<wolfspra1l> then probably some experiments with that small j1 core/soc
<wolfspra1l> bram
<azonenberg> also i have (mostly) open source code working now for downloading bitstreams over jtag
<wolfspra1l> and finally I need an efficient way to program the thing, so I look into hls now
<azonenberg> no xilinx tools needed
<azonenberg> mostly open as in my code is bsd licensed but depends on an API that is, i think, not truly FOSS
<wolfspra1l> sure, me too - it's included with fpgatools in the mini-jtag subdir
<azonenberg> at least the Digilent API is not
<azonenberg> i need to look into the FTDI api
<azonenberg> is libftdi open?
<wolfspra1l> can you look at mini-jtag ? maybe there is something I can adopt from your stuff or merge?
<azonenberg> I'll look soon
<azonenberg> My code isnt measnt for programming, though it has that capability
<azonenberg> the main point is a debug bridge for my SoC bus
<wolfspra1l> so hls? never tried?
<azonenberg> Yeah, no experience with it
<wolfspra1l> you don't know these panda/shang/legup thingies?
<wolfspra1l> ok
<wolfspra1l> azonenberg: any other news?
<wolfspra1l> how about the slx9 pics? :-)
<wolfspra1l> on my side just moving forward nicely, slow though
<azonenberg> wolfspra1l: the tungsten SEM on campus probably lacks the necessary resolutoin
<azonenberg> i need to get trained on the FESEM
<azonenberg> which happens soon
<azonenberg> i also need to get the chip decapped, havent had time to do that either
<wolfspra1l> nice
<azonenberg> i have one last stack of homework to grade and then i'm done for the semester
<wolfspra1l> I can't be that far off from finally having something that resembles a 'programmable' chip
<azonenberg> nice
<wolfspra1l> though it will require months more of work
<wolfspra1l> but the pieces are coming together and it all works well
<wolfspra1l> currently trying to finish the blinking led
<wolfspra1l> which includes clock routing, more logic features than before
<azonenberg> nice
<wolfspra1l> thinking about the coolrunners again
<wolfspra1l> make the pitch - why are those chips good?
<wolfspra1l> cheap, ok
<wolfspra1l> they integrate some flash?
<wolfspra1l> is this an area of investment or just some old chips they keep selling?
<azonenberg> They're stable and not going away any time soon, but kind of a dead end
<azonenberg> they're good for glue logic basically
<azonenberg> super tiny (think QFN32)
<azonenberg> dirt cheap, ultra-low static power
<azonenberg> 22 uA typical standby current for the xc2c32a
<azonenberg> 0.25 mA dynamic current at 1 MHz clock
<azonenberg> Basically, you use them when an FPGA is too big
<azonenberg> And they have onboard flash/eeprom so they need no external components
<wolfspra1l> hmm, ok
<wolfspra1l> I do believe in semiconductor economics, moores law etc
<wolfspra1l> so if a chip is not receiving investment, I'd rather wait and see
<azonenberg> I expect them to be EOL'd in 10 years or so
<azonenberg> not sure if they plan to replace them or not
<azonenberg> current xc2c is 130nm and there has been no shrink since then
<wolfspra1l> most likely the 'bigger' chips are actually smaller and better, only that they sell at a higher price *because* they are better and because someone is makign a healthy profit to keep investing
<wolfspra1l> which is a good thing
<azonenberg> Agreed
<azonenberg> xilinx is mostly pushing for high end
<azonenberg> cr-ii is ultra low end
<wolfspra1l> I think they push for profits, which is perfectly fine
<wolfspra1l> what is 'high-end'?
<azonenberg> So its not their focus but as long as they have the fab and masks
<wolfspra1l> don't understand
<azonenberg> and there's demand
<wolfspra1l> oh of course
<azonenberg> they'll keep making them
<wolfspra1l> of course
<azonenberg> And high end meaning high performance, lots of gates, etc
<azonenberg> look at artix7 not having anything below 100k cells
<wolfspra1l> which makes perfect sense
<azonenberg> well on 28nm you dont want to make tiny chips
<azonenberg> or your entire die is full of IOBs :P
<wolfspra1l> I will stay with the slx9 for now
<wolfspra1l> because it's cheap :-)
wolfspra1l has quit [Quit: leaving]
wolfspraul has joined #homecmos
soul-d has joined #homecmos
lekernel__ has joined #homecmos
lekernel_ has quit [Ping timeout: 245 seconds]
azonenberg has quit [Remote host closed the connection]
<lekernel__> wolfspraul: there's urjtag for programming FPGAs
<lekernel__> it's open source and reads bitfiles
<wolfspraul> yes sure but the urjtag sources are very big and it's very difficult to trace down and fix bugs in them
<lekernel__> one big benefit is you can use any jtag cable
<wolfspraul> sure I'm not against it
<wolfspraul> but I ran into urjtag bugs and (trying to) fix them took me longer than to write the few things I needed myself...
<lekernel__> and I think mwalle has been pretty efficient at implementing things and getting them to work, despite the size of the source
<wolfspraul> if urjtag works better for you - great
<wolfspraul> perfect
<lekernel__> maybe you should report those bugs (to mwalle or whoever is responsible)
<wolfspraul> hopeless case, I've moved on - but of course if urjtag works, great!
<wolfspraul> just checked again - mini-jtag with just that upload thing I needed has 375 lines of .c right now
<wolfspraul> three hundred
<wolfspraul> urjtag...
<wolfspraul> :-)
<wolfspraul> 71,908
<lekernel__> yeah but it supports a good dozen jtag cables with a thousand or so devices
<wolfspraul> of course it implements hundreds of things, I'm sure
<wolfspraul> wonderful
<lekernel__> of course everyone loves writing their own jtag hack :) I did that too...
<wolfspraul> do you know much about high-level synthesis tools?
<wolfspraul> I am reading up on legup, c-to-verilog, shang, panda, etc.
<lekernel__> yeah, I started implementing something like that in migen
<lekernel__> python subset to fhdl (and then verilog or otherwise)
<wolfspraul> did you work with some of those others before?
<lekernel__> one main benefit of doing that is you can benefit from the bus/io integration to integrate your synthesized code
<lekernel__> I have used c-to-verilog, and know a (very) little about mitrion-c
<lekernel__> also tried using ORCC (CAL-to-VHDL) but it's not really usable
<lekernel__> java based, super bloated, full of bugs and crashes every 5 min
<wolfspraul> ok, thanks
<wolfspraul> I will look at shang a little
<lekernel__> the "modulo scheduling" paper linked from c-to-verilog is interesting
<lekernel__> wolfspraul: how are you planning to handle mapping to LUT/flip-flops and place-and-route?
<wolfspraul> don't know yet
<wolfspraul> i'm busy with the bits and low-level details for some more time
<wolfspraul> my first test designs are all manually placed and then auto-routed with some very simple routing functions
<wolfspraul> I won't start with any higher layer until a larger subset of the chip's features work
<wolfspraul> right now that's maybe 1% or so ;-)
<wolfspraul> no point in thinking about mapping...
<kristianpaul> lekernel__: ah hi :-9
<kristianpaul> :-)
<kristianpaul> lekernel__: similar situation with urjag, can you patch m1 to be compatible with any serial terminal software like screen
<kristianpaul> is a shame i just can use flterm..
<kristianpaul> oops wrong channel ;)
<kristianpaul> is a simple patch but the missing carriage return stops the out of the box experience with dozens of serial port terminal software out there :-)
<kristianpaul> i think larsc already have a patch for it may be you can merge it to upstream with the 5bits csr as well ,)
<kristianpaul> ;)
azonenberg has joined #homecmos
joehot has quit [Read error: Connection reset by peer]
joehot has joined #homecmos
<kanzure> wolfspraul: can you link me to c-to-verilog things?
<kanzure> ah