<azonenberg>
lekernel: So IDK if i mentioned but i'm writing a F/OSS toolchain for coolrunner-ii CPLDs
<azonenberg>
i figure i'll let wolfspraul and company work on spartan6, thats a nice goal but is a huge undertaking
<azonenberg>
CR-II is small enough to actually be tractable for a one-man operation
<azonenberg>
I have the bitstream structure largely reversed and am able to load them into memory and serialize back to disk, then load the resulting image onto the chip
<azonenberg>
there's a handful of fields i haven't figured out (like a dozen 2-input muxes and one part of the crossbar) but another few hours of work is all that will take
<azonenberg>
then i can work on a place-and-route setup
xiangfu has joined #milkymist
<azonenberg>
xiangfu: did you miss what i just said about the CPLD stuff?
<xiangfu>
yes. I miss that.
<azonenberg>
(00:35:13) azonenberg: I have the bitstream structure largely reversed and am able to load them into memory and serialize back to disk, then load the resulting image onto the chip
<azonenberg>
(00:35:38) azonenberg: there's a handful of fields i haven't figured out (like a dozen 2-input muxes and one part of the crossbar) but another few hours of work is all that will take
<azonenberg>
(00:35:49) azonenberg: then i can work on a place-and-route setup
Hawk777 has quit [Quit: Coyote finally caught me]
Hawk777 has joined #milkymist
<azonenberg>
i did a test an hour ago of taking an object-oriented in-memory representation of a design (loaded from an ISE-generated bitstream), serializing to a bitstream, then loading onto the chip
<azonenberg>
at this point it's just figuring out which 2-bit value for a mux corresponds to which of the input choices, etc
<digshadow>
I was thinking of trying to help wolfspraul out on his project but I haven't seen him online for a while, is there another way to contact him
<lekernel>
digshadow, pull requests? ;)
<azonenberg>
he does have the stuff on github but i havent looked at it much
<azonenberg>
been busy with the CPLDs
<azonenberg>
thats a separate codebase since the architecture has basically nothing in common
<lekernel>
azonenberg, sounds cool!
<azonenberg>
lekernel: it appears XC2C has only one bit per IO bank for input and one for output standard
<azonenberg>
low range (LVCMOS18/LVCMOS15) and high (LVCMOS33/LVCMOS25/LVTTL)
<azonenberg>
the detailed standard values affect timing analysis but not the bitstream
<digshadow>
pull request did cross my mind actually :P
aeris has quit [Ping timeout: 244 seconds]
aeris has joined #milkymist
xiangfu has quit [Ping timeout: 264 seconds]
mumptai has joined #milkymist
xiangfu has joined #milkymist
<roh>
azonenberg: cool stuff. looking forward to play with it.
<roh>
heh. seems most xbox360 modchips are based on coolrunner2 *g*
<azonenberg>
roh: lol
<azonenberg>
Give me 5 mins and i'll pastebin some output
<roh>
and its 2E per chip from the first piece
<azonenberg>
Yeah
<azonenberg>
I'm only supporting XC2C32A for now but the code will scale to other stuff too
<roh>
XC2C64A-7VQG44C is what i looked up
<roh>
thats 1 euro .. wow.
<azonenberg>
Yeaj
<azonenberg>
xc2c32a is $1.20 in the US for the cheapest package/speed
<azonenberg>
only ~750 gate equivalents and 32 flipflops
<azonenberg>
but still, *any* programmable logic with a F/OSS toolchain is a lot better than none
<roh>
still quite a desk full of ttl/cmos parts without programmable logic
<roh>
true. will be quite a nice companion for small mcu
<azonenberg>
I'm just confused as to what is going on with the xilinx toolchain
<azonenberg>
going from an in-memory bitstream image for the CPLD to a ROM image takes them 1.6 seconds
<azonenberg>
my code at the moment runs in 40ms
kilae has joined #milkymist
<azonenberg>
either i'm missing something or they did something really dumb
<azonenberg>
i'm not far enough along yet to know which
<roh>
ah. dont wonder. i guess the latter
<azonenberg>
Lol
<roh>
but maybe there is some sideeffect they want to avoid/check for which isnt even important for that chip, which takes a lot of calculations.
<azonenberg>
a strace shows that they load 85KB of XML with static timing analysis info
<azonenberg>
that process has no output
<roh>
but its in the chain.... thousands of things can go weird withn big companies, their toolchains and no proper documentation
<azonenberg>
and runs on a netlist that's already placed and routd
<azonenberg>
Lol, yes
<roh>
i guess half the cpupower on this planet is wasted by stupid coders and business decisions. more on the latter than the first
<azonenberg>
Lol
<azonenberg>
The second
<azonenberg>
that screams "java" to me
<roh>
i thought so too.. but now i know tha java has a real usecase.
<azonenberg>
This is my code to date running on an XC2C32A bitstream consisting of the single verilog line "assign dout = ~din"
<azonenberg>
din is LVCMOS33 on pin 28 and dout is LVCMOS33 on pin 38
<roh>
flying crowbar? nice name :) like it
<azonenberg>
Lol
<azonenberg>
The *s in the arrays mean there's a connection, a space means no connection
<azonenberg>
Drawing a NOT gate in UTF-8 is a pain in the neck :P
<roh>
hrhr
<azonenberg>
Notice a lot of the fiedls are still numeric values
<azonenberg>
fields*
<azonenberg>
rather than descriptive names
<azonenberg>
Those are the ones i have not yet figured out
<roh>
well.. seems like details to me.. you'll figure it out
<azonenberg>
Yes
<roh>
great work anyhow. i'm impressed
<azonenberg>
I am quite confident i will have the structure mostly figured out by the end of the weekend
<azonenberg>
The next step will be to take the library and start building a place-and-route tool in front of it (given an optimized, unplaced netlist and constraints)
<azonenberg>
Then I can decide whther to try to adapt iverilog to be a front end or try to roll my own
<roh>
do you think going up and down the model chain will change much?
<azonenberg>
One design decision is final already
<azonenberg>
I am not going GPL
<azonenberg>
BSD license
<azonenberg>
The only reason for GPL is to prevent third parties from stealing your work and turning it into a proprietary product
<roh>
well.. no problem. as long as its a foss licence and not something stupid like cddl ;)
<azonenberg>
nobody but xilinx would have any reason to do that
<azonenberg>
and xilinx has a full-time team of programmers working on this
<azonenberg>
they don't need my spare-time project :p
<roh>
azonenberg: you think... well... all the current xilinx stuff was some other companies before
<azonenberg>
This entire codebase, btw, was the work of two or three days
<azonenberg>
roh: also, the bigger thing
<azonenberg>
why would anyone pay for their fork when mine is open source and costs nothing :p[
<azonenberg>
If they end up merging my code into their product i wouldn't complain
<azonenberg>
i'd be honored
<lekernel>
azonenberg, how far are you from verilog/vhdl-style synthesis?
<azonenberg>
lekernel: I'm not even touching that
<roh>
i usually do whats best for the project. if its bsd i do bsd, if its gpl i do gpl. if its nothing yet i use gpl since i want people who use it commercially to either do it opensource or pay me.
<azonenberg>
Right now what i'm doing is compiling simple dummy designs and manipulating them
<lekernel>
what's the interface to the chip you have then?
<roh>
azonenberg: fork means 'it stays open' .. thats not what happens when companies use bsd code.
<azonenberg>
roh: they'd make a private fork and commercialize it, sure
<azonenberg>
But it won't stop this version from being useful
<azonenberg>
So i really don't care
<lekernel>
direct migen/fhdl-to-cpld sounds sexy and pretty low-hanging
<azonenberg>
lekernel: XST -> cpldfit -> hprep6 -> JED file is the normal workflow
<azonenberg>
My library can do JED -> in-memory image
<azonenberg>
in-memory image -> JED
<azonenberg>
and in-memory image -> programmed CPLD
<roh>
azonenberg: well.. thats where we differ ;) i like to keep free stuff free. i see it as a step back. but i respect such decisions.
<azonenberg>
what i'm working on now is making the in-memory image be intellegible
<azonenberg>
rather than say a variable called "fb" with the value 3, which is pretty meaningless
<roh>
gotta run.. bbl
<azonenberg>
so basically creating enums for all of the muxes
<azonenberg>
figuring out how the interconnect matrix works
<azonenberg>
etc
<lekernel>
and what interface will we have once this is done?
<azonenberg>
The next step will be to use the C++ API i have now as the underlying framework for a place-and-route tool
<lekernel>
C++? urgh
<lekernel>
why not plain C?
<azonenberg>
Objects fit very nicely for what i'm doing
<azonenberg>
I could make a C front end to the PAR tool i guess
<lekernel>
use python, lua, ruby, etc. then
<azonenberg>
anyway, you'd synthesize to some kind of equation format and then feed that to the PAR tool
<lekernel>
C++ is a hateful language
<azonenberg>
I've written enough C++ i've grown to like it
<azonenberg>
But you have to use it carefully
<azonenberg>
i dont go all-out with crazy stuff
<azonenberg>
i usually treat it as C with the ability to put functions in structs :p
<lekernel>
then why not write C with functions in structs? :)
<azonenberg>
Because the syntactic sugar increases my productivity
<azonenberg>
don't like it, fork my code :P
<azonenberg>
or write a wrapper
<azonenberg>
Example JED file from the Xilinx toolchain (what my app generated that visualization from) http://pastebin.com/8pQgE7j3