well done Dave. On Mon, Jun 21, 2010 at 8:21 AM, David MacMahon <[email protected]>wrote:
> > On Jun 19, 2010, at 23:01 , David MacMahon wrote: > > I'll let you know if I figure anything out. >> > > Through multiple combinations of working 7.1 stuff and non-working 10.1 > stuff, I eventually figured out that the problem is due to that fact that > 10.1 XPS_BEE2_usr_base/system.mhs uses dcm_module version 1.00.d. For > reasons I don't understand, BEE2 usr fpga designs built with the 10.1 > toolflow work OK if the dcm_module version is changed back to version 1.00.a > (specifically the dcm_0 instance). > would regression testing have caught this ? maybe that's what you just did ! > > The only real change that I could discern between version 1.00.a (OK) and > 1.00.b (not OK) was a three cycle delay line for the DCM reset signal. It > seems innocuous enough, but for some reason it breaks things. Maybe someone > with more insights into the inner workings of EDK and BORPH can > explore/explain further. > > Unless anyone has a good reason not to, I will be committing a new version > of system.mhs that has all dcm_module versions changed back to 1.00.a. That > dcm_module version is discontinued in 11.1, but as of 11.1 system generator > has discontinued supporting virtex2pro so we would never use any later > toolflow versions for bee2 development anyway. > Sounds good to me. Mel. > > Dave > > >
