<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
<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