| --- Log opened Fri Jul 31 00:00:39 2015 | ||
| ErikZ | How can I push down an argument to the simulator from the cmdline using fusesoc? | 08:38 |
|---|---|---|
| ErikZ | I want to push down "-i" to vsim | 08:38 |
| GeneralStupid | is anyone able to help me with the XILINX ISE? | 09:48 |
| juliusb | GeneralStupid: what's the issue? | 10:41 |
| ndrw1 | I'm using ISE now with an Artix7 device - works fine. Has some problems building an atlys system. Most problems seemed to be related to constant pushing removing bits of circuit that p&r assumed they are still there. | 11:42 |
| GeneralStupid | juliusb: i want to connect my xilinx device with simulink... the problem at the moment is that i can only use std_logic and std_logic_vector as in and outputs | 11:43 |
| GeneralStupid | but i heavily use the fixed_pkg :) | 11:43 |
| ndrw1 | verification, cosimulation or hw acceleration? | 11:52 |
| GeneralStupid | hw acceleration... :) | 11:53 |
| ndrw1 | I'd probably bypass ISE and talk to the chip directly via JTAG or SPI. then you only need some generic drivers for matlab | 11:58 |
| GeneralStupid | ok... these generic drivers are the tricky part for me :) | 11:59 |
| ndrw1 | I used SPI for that, although that was more hw evaluation than acceleration. | 12:00 |
| ndrw1 | and it was plain Matlab, not simulink | 12:00 |
| GeneralStupid | thats possible with matlab? | 12:01 |
| GeneralStupid | for me its both, acceleration and verifying... | 12:01 |
| GeneralStupid | i want to know which parameters fits best and if hardware is really that big effort for this particular case... | 12:01 |
| GeneralStupid | at the moment we already have a very fast C implementation... | 12:01 |
| GeneralStupid | that thing should be used on a hearing aid device so we need to try everything out :) | 12:02 |
| ndrw1 | I used cheetah SPI dongle - it has drivers for many tools. on the chip side we had an SPI slave to AHB bridge so you could talk to anything visible to the cpu | 12:04 |
| GeneralStupid | cpu? | 12:05 |
| GeneralStupid | softcore? | 12:05 |
| ndrw1 | also, mex compilation (fiaccel) was good enough in most cases. about 100x speedup vs normal fi code | 12:06 |
| GeneralStupid | our hearing aid does not have a C Compiler, so we need to rewrite in assembler :) | 12:07 |
| GeneralStupid | i hope my hardware implementation is good enogh, dont want that :) | 12:08 |
| ndrw1 | no, that was a testchip with some hardcoded DSP logic that was attached to SOC bus | 12:08 |
| ndrw1 | still not sure what you want to do - run some simulink sims with art of the design implemented in assembler on a soft core? | 12:11 |
| GeneralStupid | i got a matlab filter from a mathematician. I made them useful in real world... and then i "translated" it to hardware... | 12:12 |
| GeneralStupid | the filter only operated on a whole audio sample... very much unusable, a lot of stuff had to be rewritten... | 12:12 |
| ndrw1 | I did something similar. implemented a fi model (with fiaccel compilation), compared the performance against the reference design whilst still in Matlab, dumped some hex patterns for input and output, reimplemented the whole thing in RTL using the patterns as a reference. | 12:18 |
| ndrw1 | no hw acceleration was required and that was several Mgates. | 12:19 |
| ndrw1 | instead of test patterns you can also generate a reference RTL from simulink but I haven't tried that | 12:20 |
| ndrw1 | have to go, ttyl | 12:21 |
| olofk | andrzejr: Saw your question about LGPL. The whole idea of using LGPL in this context is to be able to mix proprietary code with LGPL-licensed code | 21:15 |
| olofk | So you would only have to disclose potential changes in the LGPL-licensed cores that you use. | 21:15 |
| olofk | I have been talking to other projects using LGPL for IP cores (such as the OHWR team at CERN) and everyone seem to be agreeing with this interpretation | 21:17 |
| andrzejr | olofk, I assumed this is the case. But I've never seen any such exception or interpretation included in the code. | 21:21 |
| olofk | andrzejr: You're right. It would probably be beneficial to have this written down somewhere | 21:22 |
| andrzejr | for example Linux kernel's license explicitly say that syscalls are not treated as an extension to the kernel code. | 21:22 |
| olofk | juliusb created a new license for mor1kx with basically the same properties as LPGL, but more explicitly worded for FPGA/ASIC | 21:22 |
| andrzejr | I have tentatively decided to use BSD license for my contributions (or public domain for trivial additions) but I like the idea of enforcing RTL modifications to be disclosed. | 21:24 |
| olofk | andrzejr: That's a good idea. Unfortunately we will not be able to add such a paragraph to all the code, since many of the original authors have moved on | 21:24 |
| olofk | I would like to see both a BSD-like license and an LGPL-like license better suited for FPGA/ASIC, but I think that the software licenses are ok until then | 21:26 |
| andrzejr | how about LGPL in orpsoc? technically, attaching a proprietary IP to the SoC bus is extending the SoC. | 21:28 |
| andrzejr | IMHO orpsoc_top.v should not be LGPL licensed. It is only a wrapper anyway, so we do not need to be too fussy about protecting it. | 21:30 |
| olofk | andrzejr: Agreed. I've also been experimenting with autogenerating the top-level with IP-Xact, in which case it will probably just be public domain or something | 21:32 |
| olofk | I'm fine with removing licenses for top-level files that I have created | 21:32 |
| olofk | Google already removed my license in the ProjectVault repo and replaced it with their own license :) | 21:32 |
| andrzejr | I like the idea of OHDL, has juliusb discussed it with anyone (OSI, FSF)? It would be great to have it "blessed" by one of them. | 21:39 |
| andrzejr | olofk, btw, I've modified wb_data_resize.v to support 16b and mixed-size bus accesses. Works well here but I haven't checked it with other systems. | 21:44 |
| andrzejr | hmm.. timing violations with 133MHz wb_clk frequency and Artix7 -3 speed grade | 21:52 |
| andrzejr | will have to drop it to 89MHz or 66MHz (I want wb_clk to be synchronous to the 266MHz ddr2 clock) | 21:54 |
| andrzejr | Timing met at 89MHz wb_clk and speed grade -2 :-) | 22:22 |
| --- Log closed Sat Aug 01 00:00:40 2015 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!