Hi all The real problem here is that we have no control over System Generator or ISE/EDK and what FPGAs/features get supported in any release. It would also be nice to be vendor agnostic and be able to swap from Xilinx to something else if necessary.
Tools (that we had control over) that could generate readable, useful VHDL/Verilog would go a long way to solving this problem. Aaron mentioned the desire for this at the last CASPER workshop. It would involve a lot of work though. A suitable platform would need to be found. All the DSP blocks would need to be ported as well as all the scripts that tie everything together. Aaron proposed a phased approach where DSP blocks are ported but still available in Simulink, supporting existing users while allowing development of the new platform. A final evolutionary hurdle would be to port the Matlab scripts joining everything together across. This would necessitate a fork as the old Matlab scripts would not be able to access the new system and vice versa. This would be a lot of work but would be useful for many reasons. Volunteers? Regards Andrew On 19 May 2010 21:53, Laura Spitler <[email protected]> wrote: > Hi all, > > For the reasons Andrew mentioned, I think a split in the library > should happen as late as possible. While everyone means well, I'm > dubious that bugs and features would be "back applied" to older > versions. > In my experience using mlib_devel_10_1 with both 10.1 and 11.? on > Windows and Linux respectively is that it's compatible on the level > that matters. That is to say if I hit 'run xps', it works. There maybe > extraneous warning messages cropping up, but I don't think that's > reason enough to split. > In the same vein as major software revisions, I think the next library > split should happen when some major change in the library must occur > either to accommodate new hardware (i.e. Virtex-6 development for > ROACH II) or major software change (i.e. the lack of OPB buses used in > 12.1 as mentioned by David George a few days ago or another revision > change in Xilinx's blockset library). Otherwise the boundaries of what > version is used with what hardware becomes fuzzy and confusing for > those who are starting out. > When it is deemed that a split is necessary, then mlib_devel_10_1 > should be in a clean, polished state. Maybe we even drop the "devel" > from the name. > > Cheers, > Laura > > > > On Wed, May 19, 2010 at 2:34 PM, David MacMahon > <[email protected]> wrote: > > Hi, Andrew and John, > > > > On May 19, 2010, at 0:02 , Andrew Martens wrote: > > > >> It may be time to copy our libraries to an mlib_devel_11_1 revision and > >> continue from there. ROACH2 uses Virtex6 and the 10.x and earlier tools > do > >> not support it. Disadvantages are that a lot of library maintainers will > be > >> working in mlib_devel_11_1 and bug fixes, changes etc may not make it > back > >> into mlib_devel_10_1. It worked reasonably well with the move from > >> mlib_devel_7_1 to mlib_devel_10_1 though so it probably wouldn't be a > >> problem. > > > > I think this would be a good idea. This is the first time (AFAIK) that > the > > chips CASPER supports include some that are mutually exclusive in terms > of > > tool versions (i.e. no system generator v2pro support after 10.1, no v6 > > support before 11.1). > > > > On May 19, 2010, at 9:22 , John Ford wrote: > > > >> IMO, there has to be a conscious effort to maintain tools for each > >> generation of hardware, at least to some point. I think that since 10.1 > >> is the last version to support the Virtex-II Pro, it should be kept up > to > >> date and usable, at least for some time to come. > > > > I agree that ongoing support for the v2pro is very important! IMHO, > this > > means the 10.1 CASPER libraries should maintained going forward by > > back-porting relevant bug fixes, but (IMHO) it does not necessarily mean > > that every new gizmo added to the 11.1 (and future) CASPER libraries > should > > be back-ported to the 10.1 CASPER libraries. Likewise, bug fixes in the > > 10.1 libraries should be forward-ported to the 11.1 (and future) CASPER > > libraries, but some changes may not be relevant to the newer libraries. > I > > think this will end up with diverging libraries, but I suspect that the > 10.1 > > libraries are fairly stable now and won't change too much, especially as > the > > 10.1 user base inevitably shrinks over time. > > > > Does that sound reasonable? Can anyone think of an alternative approach > > that would do better at keeping existing "legacy" users happy while not > > impeding future development? > > > > Thanks, > > Dave > > > > > > >
