00:22 <cr1901_modern> Wow, radare2 looks awesome. Never heard of it until now

00:24 <felix_> it;s currently not as powerful as ida pro, but is still quite good

00:24 <felix_> maybe i also port the lm32 support to ida

00:40 <mithro> Has anyone done work on parsing the Xilinx ISE output? I know about xob's colormake.pl and https://github.com/leaflabs/xmsgs-tools

00:41 <sb0> whitequark, what are you using for the DDS?

00:42 <sb0> whitequark, maybe you should consider FPGA + DAC ;)

00:42 <sb0> cr1901_modern, reduce() is an existing python function, optree is additional code that I have removed in the new branch

00:45 <sb0> there are no problems with multiplication (since there are no overflows), and I guess synthesizers reorganize associative operations into trees just fine

00:47 <rjo> why are there no overflows?

00:47 <sb0> whitequark, (pa98) ion trap electrode drivers

00:48 <sb0> because the bit width of the multiplication is the sum of that of the operands

00:48 <sb0> if there is a truncation, it happens at the end

00:49 <rjo> hmm. is there a concise document about verilog that says these things?

01:04 <sb0> actually in verilog this isn't exactly what happens - all operands are coerced first to the same size. but it is equivalent (and modular multiplication is still associative)

01:04 <sb0> and that size is that of the output signal

01:16 <sb0> migen actually has different rules than verilog, so that stupid things as illustrated p.16 of http://www.sutherland-hdl.com/papers/2006-SNUG-Boston_standard_gotchas_presentation.pdf do not happen (-1 + 1 == 0 in all cases)

01:16 <sb0> *p.14

02:04 <rjo_> sb0: only associative if all ops and the target have the same modulus. but from what you say they do.

02:05 <rjo_> sb0: and anyway. even if migen has a different behavior, as long as it outputs verilog, it needs to map its behavior to that of verilog.

02:20 <sb0> rjo, radare2-or1k or llvm-lm32?

04:46 <whitequark> sb0: haven't decided on particular DDS yet. I do not have very strict requirements for my application

04:48 <whitequark> using FPGA+DAC to generate sine with fixed amplitude and varying frequency seems like overkill, also unnecessarily complicates board design and assembly

05:02 <sb0> touch those crappy Analog Devices DDS chips and we talk again...

05:02 <sb0> how fast does it need to be?

05:03 <sb0> I mean, what the maximum frequency is

05:04 <sb0> if you can get away with QFP packages, the board layout should be quite straightforward... you can connect the DAC pins to most FPGA pins

05:05 <sb0> so no tracks crossing etc.

05:05 <whitequark> 10MHz top

05:05 <sb0> yeah, put a lx4/lx9 and some DAC

05:05 <sb0> that would make a nice small fpga project too...

05:06 <whitequark> ugh, BGA

05:06 <sb0> no, those are available in TQ144

05:07 <sb0> would a sigma-delta DAC even work? you can generate ~1Gsps 1-bit on those chips

05:07 <whitequark> hrm

05:08 <whitequark> I think so

05:09 <sb0> also: I think we should/will get rid of the DDS on ARTIQ in the far future and replace them with fast DACs and a fat FPGA

05:10 <sb0> so this small DDS code might even be useful in the long run.

05:14 <cr1901_modern> sb0: You'd need a good LPF if you're doing delta-sigma that fast (idk the freq spectrum on the types of cap's you're using but 1GHz sounds beyond the point where caps start acting like inductors)

05:18 <whitequark> no, you only need a 10MHz filter

05:20 <cr1901_modern> Why? Just (really) oversampling?

15:45 <rjo> sb0: radare-or1k or llvm-lm32 what?