<wpwrak> hmm, is the path to the handbook really stable ? from http://www.milkymist.org/wiki/index.php?title=Flickernoise_Patching_Language
<GitHub16> [clang-lm32] jpbonn pushed 410 new commits to master: http://git.io/wjjjjw
<GitHub16> [clang-lm32/master] Fix comment (test commit) - Craig Topper
<GitHub16> [clang-lm32/master] Improved efficiency by using iterator returned by erase, rather then restarting. - Chad Rosier
<GitHub16> [clang-lm32/master] Fix typo so we don't use the wrong function for ending ObjC++ catch blocks (GNU runtimes) - David Chisnall
<GitHub39> [clang-lm32] jpbonn pushed 1 new commit to master: http://git.io/UjZPkw
<GitHub39> [clang-lm32/master] First pass at ABI description. - JP Bonn
<GitHub2> [llvm-lm32] jpbonn pushed 590 new commits to master: http://git.io/tdpZQw
<GitHub2> [llvm-lm32/master] Cleanup. Make ScalarEvolution an explicit argument of the - Andrew Trick
<GitHub2> [llvm-lm32/master] Invoke SimplifyIndVar when we partially unroll a loop. Fixes PR10534. - Andrew Trick
<GitHub2> [llvm-lm32/master] Clarify a comment. - Bob Wilson
<larsc> hm, if I want to instantiate multiple tri-state drivers and have multi-bit output and enable signals, is there a easier/better way than using a generate-loop?
<calle_> moin
<larsc> btw. are tristate drivers instanciated at the border or could they be anywhere inside the fpga?
<calle_> those are physically in the IOBs
<larsc> ok, thanks
<calle_> and some synthesis tools do wired stuff with inout type ports in "buried" entities
<larsc> i wrote a small i2c core and was just wondering if there could be any downsides for not using a inout port for the sda signal but instead have a sda_in and sda_out signal
<calle_> I had some issues with inout, but i've also seen working code, but i haven't investigated that any further
<kristianpaul> larsc: tri state inside some fpga (wich?) is used for partial reconfiguration too i remenber
<lekernel> some FPGAs have internal tri-states, but those are all obsolete now afaik
<lekernel> inouts going across the hierarchy to reach the pins as fine, the synthesis tool will do the right thing and use a correctly connected tri-state IOB
<lekernel> some coding standards recommend having inouts only at the top level - but I've never had problems not respecting this rule (only tried it on X&A FPGA's though)
<calle_> xilinx edk had that problem when the netname was changed on different hierachy levels, was a wired "bug"
<calle_> or it wasn't a bug, just me doing something wrong
<lekernel> xilinx edk has mountains of bugs and problems when you try anything else than just using the system created by the wizard
<lekernel> also, microblaze systems are slower than lm32/milkymist systems, so I don't really have a reason to use edk :-)
<larsc> i think what is nice, is that by having seperate input and output signals is that you can also implement the tri-state outside the fpga
<calle_> but there is no real way around it if you want to use the ppc405 in the virtex family ..
<lekernel> nope, you can instantiate the PPC primitive
<lekernel> it's just a bit messy
<calle_> and i'm highly likely to end up in some undocumented aspect of that system
<lekernel> by the way, your ISE installation comes with the full snake oil encrypted Verilog source code of this thing ...
<lekernel> so if you want it to work outside EDK, it will :-)
<calle_> yeah, but its kind of a dead end
<calle_> the family i likely to be discontinued
<lekernel> well, you have to balance fighting EDK issues for the duration of your complete project against figuring out once and for all how to use PPC405 instances
<lekernel> this depends on the size of your project :-)
<calle_> but a less clumsy edk would be nice
<calle_> lekernel, well its a side kick thing for me
<calle_> if it doesn't work with the edk, i'll have to scratch it